Scalable Local Cache in Distributed Streaming Platform for Real-Time Applications

ABSTRACT

Software for a distributed streaming platform receives an application. The application is structured as a directed acyclic graph (DAG) with instances of operators as nodes and streams as edges between nodes. Multiple instances of an operator access a shared database. The software receives a pre-defined hint associated with the application. The pre-defined hint sets a maximum period of time for local caching of a result from a query of the database by each of the multiple instances. The software launches the application by assigning the instances of operators to one or more containers provided by the streaming platform and initiating the streams. Each container is associated with a local cache. The software then receives a request from the application to make a dynamic adjustment that increases the maximum period of time for local caching of a result from a query of the database by each of the multiple instances.

CLAIM OF PRIORITY

This application is a continuation of U.S. patent application Ser. No.14/205,320, filed on Mar. 11, 2014, entitled “Scalable Local Cache inDistributed Streaming Platform for Real-Time Applications”, (U.S. Pat.No. 9,654,546, issued on May 16, 2017), and which further claimspriority to U.S. Provisional Patent Application Ser. No. 61/776,545,filed on Mar. 11, 2013, entitled “Real-Time Streaming Platform forHadoop” which further claims priority to U.S. Provisional PatentApplication Ser. No. 61/838,870, filed on Jun. 24, 2013, entitled “ADistributed Streaming Platform for Real-Time Applications” which furtherclaims priority to U.S. Provisional Patent Application Ser. No.61/957,267, filed on Jun. 25, 2013, entitled “Distributed StreamingPlatform for Real-Time Applications.”

RELATED APPLICATIONS

This application is related to U.S. patent application Ser. No.13/927,108, entitled “Distributed Streaming Platform for Real-TimeApplications”, filed on Jun. 25, 2013. This application is also relatedto U.S. patent application Ser. No. 13/928,357, entitled “DynamicPartitioning of Instances in Distributed Streaming Platform forReal-Time Applications”, filed on Jun. 26, 2013, now issued as U.S. Pat.No. 9,654,538, which issued on May 16, 2017, and U.S. patent applicationSer. No. 13/928,351, entitled “Checkpointing in Distributed StreamingPlatform for Real-Time Applications”, filed on Jun. 26, 2013, now issuedas U.S. Pat. No. 9,298,788, which issued on Mar. 29, 2016, and U.S.patent application Ser. No. 13/928,363, entitled “Dynamic Adjustments inDistributed Streaming Platform for Real-Time Applications”, all of whichare incorporated by reference.

Additionally, this application is related to U.S. patent applicationSer. No. 14/203,551, entitled “Thread-Local Streams in DistributedStreaming Platform for Real-Time Applications”, filed on Mar. 10, 2014,now issued as U.S. Pat. No. 9,582,365, which issued on Feb. 28, 2017.And this application is related to U.S. application Ser. No. 14/205,234,entitled “Formula-Based Load Evaluation in Distributed StreamingPlatform for Real-Time Applications”, filed on Mar. 11, 2014, now issuedas U.S. Pat. No. 9,563,486, which issued on Feb. 7, 2017, and U.S.application Ser. No. 14/205,357, entitled “Partitionable Unifiers inDistributed Streaming Platform for Real-Time Applications”, filed onMar. 11, 2014, now issued as U.S. Pat. No. 9,648,068, which issued onMay 9, 2017.

The disclosures of all of the applications identified in the aboveparagraphs are incorporated herein by reference.

BACKGROUND

Streaming applications operate on input data which is not retrieved frompersistent storage, but which arrives as one or more continuous sequenceof items. Such input data might be streaming media such as streamingaudio or streaming video. Or such input data might be other thanstreaming audio or streaming video, e.g., real-time streaming text.Examples of the latter type of input data include real-time electronicstock tickers published by financial websites such as Yahoo! Finance,CNBC, Bloomberg, or NASDAQ and real-time content streams published bywebsites such as Twitter and Facebook which leverage interest and/orsocial graphs.

As the sources of streaming data proliferate, scalability has become anissue for streaming applications that process such data and theplatforms which run the streaming applications. Outside of the area ofstreaming applications, scalability has been addressed by distributedbatch-processing platforms based on the Map-Reduce or similarframeworks. However, these platforms typically operate on input dataoriginating in persistent storage, e.g., the persistent storage of thecommodity servers that make up a Hadoop cluster. That is to say, interms of a stock-and-flow model, these platforms operate on a stockrather than a flow (or stream).

Performance is also an issue for streaming applications and theirplatforms, since it is often desirable that a streaming applicationoperate in real time or near real-time. In the past, streamingapplications achieved real-time performance by sacrificing dataintegrity or data completeness. For distributed batch-processingplatforms based on Map-Reduce and similar frameworks, real-timeperformance is often limited to accessing (e.g., using Pig, Scalding,Dremel, Drill, etc.) a store of indexed results that were generatedoffline.

Complicating matters still further, streaming applications tend to benon-stop, almost by definition. And consequently, fault tolerance is animportant issue for streaming applications and the platforms on whichthey run.

SUMMARY

In an example embodiment, a method is described. The method is executedby one or more processors in real time or near real time rather thanoffline. According to the method, software for a distributed streamingplatform receives an application that runs on the streaming platform.The application is structured as a directed acyclic graph (DAG) withinstances of operators as nodes and streams as edges between nodes.Multiple instances of an operator access a shared database. The softwarethen receives a pre-defined hint associated with the application. Thepre-defined hint sets a maximum period of time for local caching of aresult from a query of the database by each of the multiple instances.The software launches the application by assigning the instances ofoperators to one or more containers provided by the streaming platformand initiating the streams. Each container is associated with a localcache. The software monitors a performance statistic for accesses to thedatabase by each of the multiple instances and transmits results of themonitoring to the application through an application programminginterface (API) exposed by the streaming platform. The software thenreceives a request from the application through the API to make adynamic adjustment that increases the maximum period of time for localcaching of a result from a query of the database by each of the multipleinstances. And the software makes the dynamic adjustment and re-launchesthe application using a recovery policy.

In another example embodiment, an apparatus is described, namely,computer-readable storage media which persistently store a program. Theprogram might be software for a distributed streaming platform. Theprogram is executed by one or more processors in real time or near realtime rather than offline. The program receives an application that runson the streaming platform. The application is structured as a directedacyclic graph (DAG) with instances of operators as nodes and streams asedges between nodes. Multiple instances of an operator access a shareddatabase. The program then receives a pre-defined hint associated withthe application. The pre-defined hint sets a maximum period of time forlocal caching of a result from a query of the database by each of themultiple instances. The program launches the application by assigningthe instances of operators to one or more containers provided by thestreaming platform and initiating the streams. Each container isassociated with a local cache. The program monitors a performancestatistic for accesses to the database by each of the multiple instancesand transmits results of the monitoring to the application through anAPI exposed by the streaming platform. The program then receives arequest from the application through the API to make a dynamicadjustment that increases the maximum period of time for local cachingof a result from a query of the database by each of the multipleinstances. And the program makes the dynamic adjustment and re-launchesthe application using a recovery policy.

Another example embodiment involves a method. The method is executed byone or more processors in real time or near real time rather thanoffline. According to the method, software for a distributed streamingplatform receives an application that runs on the streaming platform.The application is structured as a directed acyclic graph (DAG) withinstances of operators as nodes and streams as edges between nodes.Multiple instances of an operator access a shared database. The softwarethen receives a pre-defined hint associated with the application. Thepre-defined hint sets a maximum period of time for local caching of aresult from a query of the database by each of the multiple instances.The software launches the application by assigning the instances ofoperators to one or more containers provided by the streaming platformand initiating the streams. Each container is associated with a localcache which is resizable upward or downward. The software monitors aperformance statistic for accesses to the database by each of themultiple instances and transmits results of the monitoring to theapplication through an API exposed by the streaming platform. Thesoftware then receives a request from the application through the API tomake a dynamic adjustment that increases the maximum period of time forlocal caching of a result from a query of the database by each of themultiple instances. And the software makes the dynamic adjustment andre-launches the application.

Other aspects and advantages of the inventions will become apparent fromthe following detailed description, taken in conjunction with theaccompanying drawings, which illustrates by way of example theprinciples of the inventions.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a network with a website hosting a distributedstreaming platform, in accordance with an example embodiment.

FIG. 2 is a diagram of a software stack for a distributed streamingplatform, in accordance with an example embodiment.

FIG. 3 is a diagram showing components of a real-time streamingapplication, in accordance with an example embodiment.

FIG. 4 is a flowchart diagram that illustrates a process for launching astreaming application and making dynamic adjustments based on monitoredperformance, in accordance with an example embodiment.

FIG. 5 is an illustration of the ordered tuples in a streaming window,in accordance with an example embodiment.

FIG. 6 is a diagram showing a logical plan, a physical plan, and anexecution plan, in accordance with an example embodiment.

FIG. 7A and 7B are diagrams showing examples of the static partitioningof operator instances in a physical plan, in accordance with an exampleembodiment.

FIG. 8 is a flowchart diagram that illustrates a process for recoveringfrom a failed container or server, in accordance with an exampleembodiment.

FIG. 9 is a diagram showing several stream modes, in accordance with anexample embodiment.

FIG. 10 is flowchart diagram that illustrates a process for dynamicallypartitioning operator instances, in accordance with an exampleembodiment.

FIG. 11A is a diagram showing the use of dynamic partitioning ofinstances to lessen skew resulting from “sticky key” assignment oftuples, in accordance with an example embodiment.

FIG. 11B is a diagram showing the use of a unifier instance to lessenskew resulting from “sticky key” assignment of tuples, in accordancewith an example embodiment.

FIG. 11C is a diagram showing the use of cascading unifiers for morelinear scaling, in accordance with an example embodiment.

FIG. 12 is a diagram illustrating a stream in a message queue managed bya container's buffer server, in accordance with an example embodiment.

FIG. 13 is a diagram illustrating the flow of tuples in the streams ofan operator instance with two input ports and one output port, inaccordance with an example embodiment.

FIG. 14A is diagram showing the interactions between a STRAM and a STRAMChild, in an example embodiment.

FIG. 14B is a sequence diagram showing the initiation of a streamingapplication, in accordance with an example embodiment.

FIG. 14C is a diagram showing the ongoing execution of a streamingapplication, in accordance with an example embodiment.

FIG. 15A is a logical plan for a streaming application that originatesin a stock ticker, in accordance with an example embodiment.

FIG. 15B is an execution plan for a streaming application thatoriginates in a stock ticker, in accordance with an example embodiment.

FIGS. 16A to 16E illustrate an application dashboard in a graphical userinterface (GUI) for a distributed streaming platform, in accordance withan example embodiment.

FIGS. 17A to 17C illustrate GUI views for debugging an applicationrunning on a distributed streaming platform, in accordance with anexample embodiment.

FIG. 18 is a flowchart diagram that illustrates a process for combiningtwo operator instances connected by a stream in a container, inaccordance with an example embodiment.

FIG. 19 is a sequence diagram that shows the components involved incombining two operator instances connected by a stream in a container,in accordance with an example embodiment.

FIG. 20 is a diagram showing the combination of two operator instancesconnected by a stream in a container, in accordance with an exampleembodiment.

FIG. 21 is a diagram showing the call stacks for a combined operatorinstance resulting from the combination of two operator instancesconnected by a stream in a container, in accordance with an exampleembodiment.

FIG. 22 is a flowchart diagram that illustrates a process for creating adynamic partition using a pre-defined hint, in accordance with anexample embodiment.

FIG. 23 is a sequence diagram that shows the components involved increating a dynamic partition using a pre-defined hint, in accordancewith an example embodiment.

FIG. 24 is a flowchart diagram that illustrates a process using ascalable local cache in a container and a pre-defined hint, inaccordance with an example embodiment.

FIG. 25 is a sequence diagram that shows the components involved in aprocess using a scalable local cache in a container and a pre-definedhint, in accordance with an example embodiment.

FIG. 26 is a diagram showing a scalable local cache in a container, inaccordance with an example embodiment.

FIG. 27 is a flowchart diagram that illustrates a process usingpartitionable unifiers, in accordance with an example embodiment.

FIG. 28A is a diagram showing three use cases that do not usepartitionable unifiers, in accordance with example embodiments.

FIG. 28B is a diagram showing a use case that uses partitionableunifiers, in accordance with an example embodiment.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth inorder to provide a thorough understanding of the example embodiments.However, it will be apparent to one skilled in the art that the exampleembodiments may be practiced without some of these specific details. Inother instances, process operations and implementation details have notbeen described in detail, if already well known.

FIG. 1 is a diagram of a network with a website hosting a distributedstreaming platform, in accordance with an example embodiment. Asdepicted in this figure, a personal computer 102 (e.g., a laptop orother mobile computer) and a mobile device 103 (e.g., a smartphone suchas an iPhone, Android, Blackberry, etc.) are connected by a network 101(e.g., a wide area network (WAN) including the Internet, which might bewireless in part or in whole) with a website 104 hosting a distributedstreaming platform. In turn, website 104 is connected by the network 101to a website generating streaming data in real-time (other thanstreaming audio or streaming video), such as Yahoo! Finance or Twitter.(In some of the examples described below, the stock ticker for Yahoo!Finance is used for illustrative purposes. However, other stock tickerssuch as CNBC, Bloomberg, and NASDAQ could easily have been substituted.)In an example embodiment, personal computer 102 and mobile device 103might be used by end users who want to run and/or view a streamingapplication (e.g., a GUI dashboard) on website 104.

In an example embodiment, the website 104 might be composed of a numberof servers connected by a network (e.g., a local area network (LAN) or aWAN) to each other in a cluster or other distributed system which mightrun website software (e.g., web server software, database software,etc.) and distributed-computing software. In an example embodiment, thewebsite 105 might also be composed of a number of servers connected by anetwork to each other in a cluster or other distributed system whichmight run website software (e.g., web server software, databasesoftware, etc.) and distributed-computing and/or cloud software such asHadoop, Hadoop Distributed File System (HDFS), Pig, CloudBase, etc. Theservers at website 105 are also connected (e.g., by a storage areanetwork (SAN)) to persistent storage 106. Persistent storage 106 mightinclude a redundant array of independent disks (RAID) and/or flashmemory. Persistent storage 106 might be used to store data related tothe data streamed by website 105, e.g., financial data, content data forsocial/interest networks, etc.

In an alternative example embodiment, the servers in website 104 andwebsite 105 and the persistent storage 106 might be hosted wholly orpartially off-site in the cloud, e.g., as a platform-as-a-service (PaaS)or an infrastructure-as-a-service (IaaS).

FIG. 2 is a diagram of a software stack for a distributed streamingplatform, in accordance with an example embodiment. As depicted in thisfigure, real-time applications 201 (RT App₁, RT App₂, etc.) might run ona distributed streaming platform 202, which, in turn, might beintegrated with a distributed computing framework 203 such as YARN, inan example embodiment. YARN is in the Hadoop family of software butincludes functionality for handling distributed computations that arenot structured as batch jobs for Map-Reduce processing, includingdistributed computations that are streaming.

In turn, the distributed computing framework 203 might be supported bydistributed storage 204, which might be Hadoop Distributed File System(HDFS), in an example embodiment. And the distributed computingframework 203 and distributed storage 204 might run on a networkedcluster of servers (e.g., commodity servers) or other hardwarecomputation units (e.g., the hardware computation units emanating fromFacebook's Open Compute Project).

FIG. 3 is a diagram showing components of a real-time streamingapplication, in accordance with an example embodiment. As depicted inFIG. 3, such a streaming application might be included in aspecification 301 which might be a Java source code program, in anexample embodiment. Alternatively, specification 301 might be aHadoop-style properties file. Specification 301 includes a logical planthat is a directed acyclic graph (DAG) whose nodes are operators 302 andwhose edges are steams 303. As described in further detail below, anoperator might be a sequence of program instructions, e.g., to compute aparticular statistic. And a stream might be sequence of streamingwindows that contain tuples that (a) are structured according to aschema and (b) originates in a source outside of the applicationprogram, e.g., a stock ticker or a content stream broadcast by asocial/interest network. Specification 301 also includes configurableapplication settings 304 (e.g., with corresponding default values beingspecified by the distributed streaming platform), such as streamingwindow size (e.g., as measured in terms of units of time or number oftuples), heartbeat interval or period(e.g., as measured in terms ofunits of time or number of streaming windows), frequency ofcheckpointing (e.g., as measured in terms of units of time or number ofstreaming windows), frequency of purge determinations (e.g., as measuredin terms of units of time or number of streaming windows), aggregateapplication window size (e.g., as measured in terms of units of time ornumber of streaming windows), sliding application window size andincrementation (e.g., as measured in terms of units of time or number ofstreaming windows), etc., in an example embodiment. Additionally,specification 301 might include logic 305 (GUI logic) and logic 306(model or business logic not contained in the operators).

In an example embodiment, logic 305 and logic 306 might includemodel-view-controller (MVC logic) for displaying the results of some orall of the operators 302 in a dashboard that is part of a graphical userinterface (GUI). In an example embodiment, if the origin of thestreaming data is a stock ticker, the dashboard might display statisticsrelated to stock prices and stock sales. Or if the origin of thestreaming data is a content stream broadcast by a social/interestnetwork, the dashboard might display statistics related to socialsignals (e.g., likes, favorites, shares, etc.) related to posts to thecontent stream.

FIG. 4 is a flowchart diagram that illustrates a continuous or nonstopprocess for launching a streaming application and making dynamicadjustments based on monitored performance, in accordance with anexample embodiment. In an example embodiment, this process might beperformed by the Streaming Application Master (STRAM). In an alternativeembodiment, some or all of the operations of this process might beperformed by the STRAM Childs (e.g., slaves) or other software in thedistributed streaming platform.

As depicted in FIG. 4, the software (e.g., the STRAM) receives aspecification (e.g., whose location is identified in a user or scriptcommand on a command line interface (CLI)) for an application that isstreaming, in operation 401. In an example embodiment, the specificationmight be a source program in Java created in an integrated developmentenvironment (IDE) such as Eclipse or NetBeans. In another exampleembodiment, the specification might be a Hadoop-style properties file.Or the application might be specified at the CLI, e.g., through userinput such as macros, as described below. In operation 402, the softwareconverts the specification into a logical plan that includes a directedacyclic graph (DAG) or other precedence graph with operators as nodesand streams as edges. One might think of the logical plan as specialform of a data object model (DOM). The operators are programinstructions and the streams are unbound sequences of streaming windowsthat are ordered in terms of time. In an example embodiment, thesequence might originate from web-services interface, e.g., a web APIexposed by Yahoo! Finance or Twitter accessed by an input adapter forthe distributed streaming platform. It will be appreciated that a HadoopMap-Reduce application can be represented as a DAG, though suchapplications tend to operate on batches of data rather than streams ofdata.

In operation 403, the software translates the logical plan (e.g., theDAG) into a physical plan using any stream modes specified in thespecification (e.g., in-line, in-node, in-rack, or other) and with oneor more of instances of the operators per the static partitioning (e.g.,as expressed in partition counts) in the specification. In operation404, the software obtains a number of containers (or processes) runningon a networked cluster of servers (or other physical computationalunits). In an example embodiment, the software might obtain thesecontainers from the YARN Resource Manager. One might regard a containeras a permission from YARN to run a process on a particular server (orother physical computation unit) in the networked cluster. And one mightregard the YARN Resource Manager as a distributed operating system (OS)that manages processes, memory, and persistent storage for the networkedcluster. One slave (e.g., a STRAM Child) might execute in eachcontainer, in an example embodiment. Then in operation 405, the softwareassigns the instances of the operators to the slaves for executionaccording to an execution plan that depends on the physical plan and thenumber of containers obtained. In operation 406, the software launchesthe execution plan using input adapters which convert external inputinto tuples grouped into streaming windows. And each slave monitors thethroughput of streaming windows through the instances in its container(e.g., by monitoring the ordinal streaming window identifiers), alongother statistics related to service level and/or performance in general(e.g., latency between servers (e.g., as reported by the container),network usage (e.g., as reported by the container), CPU usage (e.g., asreported by the container), memory usage (e.g., as reported by thecontainer), uptime, errors including data loss (e.g., as reported byerror tuples/ports/streams), size of message queues managed by bufferservers, throughput other than operator throughput (such as streamthroughput or message-queue throughput), operator skew, time delay withrespect to external system components, etc.) and reports the results(e.g., in conjunction with a heartbeat protocol), in an exampleembodiment. In an example embodiment, the software might also monitorservice level and/or performance in general using statistics (e.g.,latency between servers, network usage, CPU usage, memory usage, uptime,etc.) received from or reported by the Resource Manager or othercomponents of the distributed streaming platform.

In operation 407, the software makes one or more dynamic adjustmentsbased on the results of the monitoring (e.g., to reduce traffic ofstreaming windows through message queues in containers, through serverNICs, and other bottlenecks or more generally to improve performance asmeasured by the reported statistics). In an example embodiment, thedynamic adjustments might include updating the physical plan by addingnew instances of operators or deleting existing instances of operators.Or the dynamic adjustments might update the execution plan by returninga container to the YARN Resource Manager and/or obtaining a newcontainer from the YARN Resource Manager for a rack and/or server (orother physical computational unit) and/or moving instances of operatorsfrom one container or server to another. As described in further detailbelow, the making of dynamic adjustments (e.g., failover and dynamicpartitioning) includes re-initiating the streams in accordance with arecovery policy (e.g., at least once, at most once, exactly once)through commands (e.g., from the STRAM) to the slave (e.g., STRAM Child)which, in turn, controls the operators in the container and the bufferserver in the container. Also, in an example embodiment, the dynamicadjustments might originate from commands entered by a user or theapplication at a CLI that supports runtime modifications to the logicalplan (e.g., a macro, code, an interface or API, a GUI, text input,etc.), the physical plan, and/or the execution plan.

In an example embodiment, the distributed streaming platform mightsupport a macro that is a set of CLI instructions that insert a sub-DAG(which might be reusable and therefore a candidate for a library),consisting of multiple operators and streams, into an application atruntime. The distributed streaming platform might also supporthierarchical operators that are reusable sub-DAGs which are insertedinto logical plans prior to runtime.

Then in operation 408, the software outputs structured tuples (e.g.,using output adapters) from some or all of the instances to a display(e.g., a graphical user display or GUI dashboard for decision support),to persistent storage (e.g., using HDFS) for subsequent use by anotherapplication, to another system, etc. As noted on FIG. 4, each of theoperations in this process might be executed in real time or near realtime rather than offline, in an example embodiment. Moreover, some ofthe operations described in the process, e.g., the monitoring, makingdynamic adjustments, and output operations, might be continuous ornon-stop operations, in an example embodiment.

In an example embodiment, each container might be a multi-threadedprocess that includes one thread for each operator instance, one threadfor the container's buffer server, and one thread for the slave (e.g.,STRAM Child). In an example embodiment, each container has a singlebuffer server which manages, for the operator instances in thecontainer, a message queue (FIFO not priority) of streaming windows, ona per port basis (e.g., the buffer server keeps track of which port hasread which tuple). Each of these threads might perform its computationsin memory, spilling over to persistent storage such as HDFS only in theevent that memory is insufficient. It will be appreciated that by usinga single thread for each operator, each operator can executeasynchronously without creating memory/storage incoherency.

In an example embodiment, each tuple might be a Plain Old Java Object(POJO), structured according to a schema or data type. In an exampleembodiment, each stream might have one upstream operator and onedownstream operator. In that event, the schema for a tuple also definesa schema for a stream, e.g., by defining a schema for the output port ofthe stream's upstream operator that is the same as the schema for theinput port of the stream's downstream operator. In an exampleembodiment, each operator might have one output port but one or moreinput ports which are mapped to the operator's one output port by thelogic in the operator. For example, the input to an instance of anoperator that computes an average price might be a streaming window thatconsists of a begin window (e.g., a control tuple with a field for anidentifier, say 70), followed by data tuple with a field for a price,say 221.00, followed by an end window (e.g., a control tuple with afield for an identifier, also 70). The instance might re-compute anexisting average using the new price to obtain a new average of, say230.00, and then output (or emit to an output port) a begin window(e.g., with an identifier 70), a data tuple with a field for an averageprice set to 230.00, and an end window (e.g., with an identifier 70). Itwill be appreciated that the tuple input to the instance might alreadyhave a field for an average price which is set to 230.00 by theinstance. Or alternatively, the instance might dynamically allocate thetuple with the field for an average price and set it to 230.00; thetuple might then be de-allocated by a downstream operator, e.g., adownstream operator that is an output adapter that displays the averageprice of 230.00 in a GUI dashboard. In an example embodiment, aninstance of an operator might be used to change the schema of a tuple,without making changes to any values in the schema's fields. Inoperation 402, the DAG includes operators that are program instructions.In an example embodiment, these program instructions might relate to thebusiness logic for the application, e.g., computing a financialstatistic (e.g., such as the high or low price for a stock within aperiod of time) for display in a GUI dashboard for an application fed bya stock ticker (e.g., through a web API). Or the program instructionsmight be more generic, along the lines of the C-runtime library or theC++ template library. In that regard, a library of reusable common orstandard operator templates (e.g., for use by developers of applicationsfor the distributed streaming platform) might include operator templateswith functionality for: (1) matching tuples and emitting results (wherethe output might be tuples that matched, tuples that did not match, aBoolean flag, etc.); (2) recording tuples; (3) counting items such askeys, frequency of keys, unique counts, etc.; (4) filtering such thingsas streams with input schema using keys or rates (e.g., sampling rates);(5) filtering log file lines from Apache and Tomcat servers; (6) joiningand sorting items; (7) indexing (or mapping, including hash-mapping) forsuch operations as search indexing, word-counting, etc.; (8)consolidating schemas (e.g., to consolidate multiple streams into oneschema); (9) inputting data into the application (e.g., an inputadapter) and outputting data from the application (e.g., an outputadapter), including adapters using Hadoop Distributed File System(HDFS), MemCache, MySQL, MongoDB, console, HTTP, Apache ActiveMQ,RabbitMQ, ZeroMQ, Kafka, Kestrel, Redisetc., Websocket, LocalFile, etc.;(9) performing mathematical operations such as compare, max, min,average, sum, quotient, range, except, margin, change, etc.; (10)managing streams without changing tuples or schema, e.g., streamduplicator, stream merger, array-list splitter, hash-map splitter,dev/null/counter, etc.; (11) generate load for testing, e.g., eventgenerator, random generator, filter event generator, etc.: (12)computing over application windows that are sliding; (13) generatingdata for charts (e.g., in conjunction with CLI macros that are inserteddynamically at runtime through the CLI); (14) allow the usage oflanguages such as Python, JavaScript, Bash, etc.; (15) issue alertsusing SMTP (Simple Mail Transfer Protocol); and (16) utility functionsthat are building blocks for other operator templates, including thoselisted above. In operation 402, the DAG includes edges that are streamsmade up of streaming windows. In an example embodiment, each streamingwindow is an atomic microbatch of sequential tuples that is associatedwith a recovery policy for an application. In an example embodiment, thelength of the sequence of tuples in a streaming window is variable inlength, e.g., configurable by the user directly or indirectly; astreaming window begins with a special “begin window” tuple (e.g., acontrol tuple) and ends with a special “end window” tuple (e.g., acontrol tuple). In an example embodiment, a streaming window might bespecified in terms of time as approximately 0.5 seconds. An alternativeexample embodiment might use only a single control tuple (e.g., “beginwindow”) or some other form of timestamp ordering for concurrencycontrol (e.g., isolation within the meaning of the ACID or Atomicity,Consistency, Isolation, Durability properties for reliable dataprocessing).

Other control tuples might include checkpoint tuples that are insertedinto the streaming data periodically, per the checkpointing interval (orfrequency) specified by the user or application (e.g., directly orindirectly through the recovery policy). In an example embodiment,checkpoint tuples might be inserted by an input adapter, triggeringcheckpoints as they work their way through all of the application'soperators, and be removed by an output adapter. It will be appreciatedthat checkpoint tuples can be used to achieve checkpointing at the endof streaming windows (e.g., align checkpoints with boundaries ofstreaming windows).

In an example embodiment, an instance of an operator might report errors(e.g., counted per streaming window) using an error tuple that isemitted through an error port (e.g., an output port for an error stream)to a log file (e.g., in HDFS). Also, in an example embodiment, an inputadapter might use a sample operator to perform bucket testing on newapplication logic on a relatively small subset of a stream, beforedeployment to the application.

In an example embodiment, an application window might be specified as interms of streaming windows or using a period of time. In an exampleembodiment, an application window specified in terms of time might rangefrom 5 to 15 minutes. Also, in an example embodiment, the defaultapplication window might be a single streaming window. An applicationwindow is associated with an operator; thus an application might havemultiple application windows. Also, in an example embodiment, anapplication might be either an aggregate application window or a slidingapplication window.

An aggregate application window is constructed by combining a number ofconsecutive streaming windows without overlapping. That is to say, thenext application window begins only after the current application windowends, in an example embodiment. Aggregate application windows are usedfor stateless application operators, e.g., application operators thatoperate solely on data in the streaming windows without resort to dataread into memory from persistent storage. It does not follow that theoperator instances in the physical plan are stateless; they arestateful, in an example embodiment. In an example embodiment, thedistributed streaming platform might enhance performance of an aggregateapplication window by using one begin window tuple (e.g., aligned withthe window boundary of the aggregate application window) and one endwindow tuple (e.g., also aligned with the window boundary of theaggregate application window) for all of the streaming windows in theaggregate application window; that is to say, the intervening controltuples (e.g., begin window tuples and end window tuples) might not beprocessed by the operator associated with the aggregate applicationwindow, though they might be used for monitoring purposes (e.g., by theSTRAM child and/or buffer server). Also, in an example embodiment, thedistributed streaming platform (e.g., STRAM) might use the laststreaming window in an aggregate application window when making a purgedetermination as described in further detail below. An example of anoperator that might be used with an aggregate application window in afinancial application is an operator that charts stock ticker data on aper minute basis.

A sliding application window is constructed by combining a number ofconsecutive streaming windows with overlapping. That is to say, thecurrent sliding application window is formed by dropping a streamingwindow from the previous sliding application window and adding a newstreaming window, in an example embodiment (e.g., sliding by onestreaming window). Sliding application windows are used for statefulapplication operators and the operator instances in the physical planare also stateful, in an example embodiment. An example of an operatorthat might be used with a sliding application window in a financialapplication is an operator that counts the top 10 trades in terms ofvolume on a stock ticker over the past minute (e.g., starting from now).

Again, the use cases are many, and financial applications are mentionedbecause they are a type of process that benefits from real-time or nearreal-time processing. So therefore, the types of applications that canbenefit from the processing described herein can be large, and withoutlimitation and for purposes of example only, such applications can befor processing technical computing data, computing statistics, dataprocessing statistics, advertising statistics, gaming statistics,hospital resource management, traffic statistics, application loadmanaging, distributed processing, load balancing of servers andprocesses, inventory statistics, data distribution statistics, and othertypes technology driven processes.

Also, in an example embodiment, the recovery policy might beconfigurable by the user of the application or the application itself.Such configuration might occur prior to launch or during runtime, e.g.,through the CLI. The recovery policy might be one of at least once, atmost once, or exactly once, as described in further detail below. Therecovery policy might impact performance of the distributed streamingplatform because it can affect of the frequency of instancecheckpointing, e.g., when the recovery policy is exactly once, instancecheckpointing will occur at the end of every streaming window. In anexample embodiment, instance checkpointing involves (a) pausing aninstance of an operator at the end of a streaming window, (b)serializing the instance to persistent storage, e.g., usingfunctionality such as Kryo to serialize the instance to a file in a filesystem such as Hadoop Distributed File System (HDFS), and (c) notifyingthe STRAM of the last window completed. Also, in an example embodiment,instance checkpointing might occur at a specified time period, e.g.,every 30 seconds, which might be configurable by the user of theapplication, e.g., when the recovery policy is other than exactly once.

It will be appreciated that the statefulness of the instance mightdetermine the amount of data to be serialized, in an example embodiment.For example, if an operator is stateless (e.g., it operates solely onthe tuples in a streaming window without resort to data of its own readinto memory from persistent storage), serialization of the operatormight be skipped.

In an example embodiment, the recovery policy might be specified on aper-operator basis or a per instance basis. That is, there might bedifferent recovery policies for different operators or for differentinstances of the same operator. So, for example, a stateful instancemight have a recovery policy of at least once or exactly once, whereas astateless instance might have a recovery policy of at most once.

Traditionally, the state of a streaming application is defined as thestate of all operators and the state of all streams. In an exampleembodiment, the state of the streaming application might be defined asthe state of all operator instances (e.g., one or more serializations ofthe instance obtained through checkpointing) and the set of allstreaming windows in the message queues maintained by the bufferservers. It will be appreciated that in such an embodiment, the state ofan operator instance is associated with an identifier for a streamingwindow. In an example embodiment, the checkpointing might beasynchronous insofar as the latest serialization (or checkpoint) for oneinstance of an operator might be at the end of a streaming window whoseidentifier differs from that of the latest serialization (or checkpoint)for another instance. Also in an example embodiment, if multipleserializations are stored for an operator instance, STRAM might purgeearlier serializations on a FIFO basis consistent with the recoverypolicy.

In an example embodiment, the STRAM might dump the current state of alloperator instances (including additions, deletions, movements to othercontainers, etc.) to a change file (e.g., in HDFS). It will beappreciated that the distributed streaming platform might then use thischange file to create an updated logical plan, which might be used tore-launch the application, e.g., in the event of a grid outage in thenetworked cluster. Such a change file might be updated (a) at arecurring time period that is configurable by the user or theapplication, or (b) as a result of a command at the CLI, e.g., by theuser or an application.

In operation 406, the slaves (e.g., STRAM Childs) might report theresults of their monitoring (e.g., to the STRAM) in conjunction with aheartbeat protocol. Also, in an example embodiment, the heartbeatinterval or period might be configurable by the user of the application,e.g., either in terms of units of time or number of streaming windows.In an example embodiment, the heartbeat protocol might use YARN RPC(remote procedure call). It will be appreciated that a heartbeatinterval that is too short might add considerable network traffic andresultant computation to the distributed streaming platform.

In any event, the reporting of the results of the monitoring might bealigned with a streaming window boundary, e.g., through an end window.That is to say, the reporting of the results might take place during theperiod of time between an end window and the next begin window, in anexample embodiment. This period of time might also be used forrestarting operators (e.g., during server outages), checkpointing,checksumming, and other statistics generation, etc. In an exampleembodiment, class-method calls might be associated with begin windowtuples and end window tuples. And in such an example embodiment, theclass-method call for end window might perform some or all of thereporting of the results of the monitoring, restarting operators,checkpointing, checksumming, and other statistics generation.

It will be appreciated that each streaming window is identified by anordinal identifier that increases as the application runs (e.g., 1, 2,3, etc.). In an example embodiment, the results of the monitoring inoperation 406 might include (a) the identifier for the last processedstreaming window per operator in the container, (b) the identifier forthe last checkpoint streaming window per operator in the container, and(c) the identifier for the committed streaming window. The committedstreaming window is the streaming window that has been computed by alloutput adapters (e.g., operators which write to console or persistentstorage). In an example embodiment, the STRAM uses (b) and (c) todetermine which streaming windows can be purged from the buffer server'smessage queue in each container and which checkpoint serializations (orfiles) can be purged from persistent storage (e.g., HDFS). In an exampleembodiment, the user of the application might configure the period atwhich this purge determination is performed by the STRAM, e.g., every 30seconds.

In another example embodiment, the results of the monitoring might alsoinclude some statistics related to streams, e.g., tuples consumed ateach input port of an operator per second, tuples emitted to or by eachoutput port of an operator per second, etc. Also, each buffer servermight also report monitoring results related to the streaming windows inits message queue, the identifier of the last streaming window in themessage queue, confirmation of the purge of a streaming window in themessage queue, etc.

In operation 407, the software re-initiates the streams in accordancewith a recovery policy when making dynamic adjustments. In an exampleembodiment, the recovery policy might be one of at least once, at mostonce, exactly once, by analogy to the delivery assurances in theWS-Reliable Messaging Protocol. These recovery policies are described ingreater detail in FIG. 8, in a context where a dynamic adjustmentresults from failure of a container or its server (e.g., failover).

FIG. 5 is an illustration of the ordered tuples in a streaming window,in accordance with an example embodiment. In this figure, time movesalong a horizontal axis to the left, so streaming window 501 (n) isearlier in time than streaming window 502 (n+1). As shown in thisfigure, a stream (e.g., an edge in the logical plan) might be acontinuous stream of in-order streaming windows (e.g., 501 and 502),which, in turn, are a continuous stream of in-order tuples (e.g., tuple503), which might be thought of as records, structs, or classes withonly data members and no methods, structured according to a schema ordata type. Also shown in this figure are control tuples 504 (beginwindow n), 505 (end window n), 506 (begin window n+1), and 507 (endwindow n+1), which might not contain data related to the application, inan example embodiment.

FIG. 6 is a diagram showing a logical plan, a physical plan, and anexecution plan, in accordance with an example embodiment. This figureshould be read from top to bottom; that is to say, a logical plan 601precedes a physical plan 602, which precedes an execution plan 603, perthe flowchart in FIG. 4. As indicated in FIG. 6, the application is afinancial application whose streaming data originates in a stock ticker,e.g., Stock Tick Input 1 in each of the plans. In an example embodiment,a user of the distributed streaming platform might have input (e.g.,provided the location of the application's files) logical plan 601through a CLI. The logical plan includes four operators: (a) Stock TickInput 1; (b) Daily Volume 2; (c) Quote 3, and (d) Console 4 (e.g.,output to a display). The distributed streaming platform (e.g., theSTRAM) converts the logical plan 601 into a physical plan 602 bystatically partitioning the operator Daily Volume 2 into three instances(e.g., per a partition count in the specification): instance DailyVolume 2_1, instance Daily Volume 2_2, and instance Daily Volume 2_3,each of which might be a thread. Then the distributed streaming platform(e.g., the STRAM) connects the three instances to the upstream instanceStock Input 1 using a stream duplicator 604 and connects them to thedownstream instance Quote 3 using a stream merger (or unifier) 605. Thedistributed streaming platform (e.g., the STRAM) then obtains 3containers (e.g., processes) from a resource manager (e.g., a YARNResource Manager) and, to complete the execution plan, assigns (a)instance Daily Volume 2_1 to container 1, (b) instance Stock Tick Input1, instance Daily Volume 2_2, instance Quote 3, and instance Quote 4 tocontainer 2, and (c) instance Daily Volume 2_3 to container 3. Such anexecution plan might work well with a stream codec whose hash functionresults in a high throughput of tuples through instance Daily Volume2_2, since that throughput could avoid passing through a buffer server'smessage queue.

FIG. 7A and 7B are diagrams showing examples of the static partitioningof operator instances in a physical plan, in accordance with an exampleembodiment. As depicted in FIG. 7A, a logical plan (or DAG) 701 includesfour operators: operator 0, operator 1, operator 2, and operator 3.According to the static partitioning (e.g., partition counts) in thespecification for the logical plan 701, the distributed streamingplatform (e.g., the STRAM) could partition operator 1 into threeinstances, 1 a, 1 b, and 1 c, and operator 2 into two instances, 2 a and2 b, using one unifier for the three instances of operator 1 and oneunifier for the two instances of operator 2, when creating the physicalplan (or DAG) 702. However, this partition might create a bottleneck atthe unifier for the three instances of operator 1. So the distributedstreaming platform (e.g., the STRAM) instead creates a physical plan (orDAG) 703, in which there are two unifiers for the three instances ofoperator 1. It will be appreciated that such an approach might also beused for dynamic partitioning based on the results of the instancemonitoring described above.

FIG. 7B also depicts a logical plan (or DAG) 711. This logical planincludes five operators: operator 0, operator 1, operator 2, operator 3,and operator 4. Note that the throughput is expected to be large on thestream connecting operator 0 to operator 1 and the stream connectingoperator 1 to operator 2, as indicated by the thickness of the streams.These expected throughputs might be communicated by the user in thespecification, in an example embodiment. According to the staticpartitioning (e.g., partition counts) in the specification for thelogical plan 711, the distributed streaming platform (e.g., the STRAM)could partition operator 1 into two instances, 1 a and 1 b, using oneunifier for the two instances of operator 1, when creating the physicalplan (or DAG) 712. However, this partition might create a bottleneckwith large throughput from the unifier to operator 2. So the distributedstreaming platform (e.g., the STRAM) instead creates a physical plan (orDAG) 713 with a parallel partition that avoids large throughput andbottlenecks. In the parallel partition, the large throughput out ofoperator 0 is split between two branches; one with instances 1 a ofoperator 1, 2 a of operator 2, and 3 a of operator 3, and another withinstances 1 b of operator 1, 2 b of operator 2, and 3 b of operator 3.The two branches are then merged through a unifier that outputs a singlestream to operator 4. It will be appreciated that such splitting andmerging (which is also referred to as fan-out and fan-in, respectively)might be used to process a Map-Reduce application that is ultimatelywritten to a file (e.g., an HDFS file), in an example embodiment. Itwill also be appreciated that such an approach might also be used fordynamic partitioning based on the results of the instance monitoringdescribed above.

In an example embodiment, the distributed streaming platform (e.g., theSTRAM) might ignore all or part of the static partition, treating it asa hint rather than a command. In that event, the software might issue adiagnostic message (e.g., through the CLI or to a log file) to the userwho submitted the application.

FIG. 8 is a flowchart diagram that illustrates a process for recoveringfrom a failed container or server, in accordance with an exampleembodiment. It will be appreciated that such recovery (e.g., failover)is a form as dynamic adjustment based on monitoring results, asdescribed above. In an example embodiment, this process might beperformed by the STRAM. In an alternative embodiment, some or all of theoperations of this process might be performed by the STRAM Childs orother software in the distributed streaming platform.

As depicted in FIG. 8, the software (e.g., the STRAM) determines that acontainer or its server has failed (e.g., based on notification fromYARN Resource Manager, a time out on heartbeat to slave, an exceptionrepeatedly thrown by an instance in the container, etc.), in operation801. In operation 802, the software obtains a new container (e.g., fromthe YARN Resource Manager) and assigns instances of operators to thecontainer per the original execution plan or per an updated executionplan based on the monitoring results reported by slaves (e.g., STRAMChilds).Then in operation 803, the software restarts the applicationaccording to the following recovery policies: (A) if the recovery policyis at most once (e.g., data loss is acceptable), then the softwareinstructs (e.g., through the STRAM Child) each instance in the newcontainer to subscribe to the next streaming window in the upstreambuffer server's message queue (or, alternatively, instructs the upstreambuffer server through a STRAM Child to transmit that streaming window toeach of those instances); (B) if the recovery policy is at least once(e.g., data loss is not acceptable but extra computations are), then (1)the software determines the latest viable checkpoint for each instancein the new container using streaming window identifiers of checkpointsfor that instance and for downstream instances (e.g., the streamingwindow identifier of the latest viable checkpoint is less or older thanthe streaming window identifiers of the checkpoints for the downstreaminstances); (2) restarts (e.g., through the STRAM Child) each instancein the new container using the latest viable checkpoint and restarts(e.g., through the STRAM Childs) the downstream instances using each oftheir latest checkpoints (e.g., with each of the downstream instancesbeing instructed to subscribe to the streaming window in each of theirupstream buffer server's message queues with a streaming windowidentifier greater or newer than each of their latest checkpoints), and(3) instructs (e.g., through the STRAM Child) each instance in the newcontainer to subscribe to the streaming window in the upstream bufferserver's message queue with a streaming window identifier that isgreater or newer than the streaming window identifier of the latestviable checkpoint; or (C) if the recovery policy is exactly once (e.g.,data loss is not acceptable and neither are extra computations), thenthe software restarts (e.g., through the STRAM Child) each instance inthe new container using the last checkpoint (its streaming windowidentifier will be less or older by one) and instructs (e.g., throughthe STRAM Child) each of those instances to subscribe to the streamingwindow in the upstream buffer server's message queue that was lost (notcheckpointed).

It will be appreciated that the recovery policy of at most once can beprocessed faster than a recovery policy of at least once and exactlyonce, at the cost of data loss. And while a recovery policy of exactlyonce might be processed faster than a recovery policy of at least once,the former recovery policy might significantly impact performance of thedistributed streaming platform since it requires the checkpointing of aninstance at the end of every streaming window.

It will also be appreciated that operations 802 and 803 might also beused during other dynamic adjustments as described above, e.g., addingnew containers to an updated execution plan, based on monitoring resultsfrom the slaves or a command (e.g., a macro) entered by a user or scriptat the CLI while the application is continuously executing.

FIG. 9 is a diagram showing several stream modes, in accordance with anexample embodiment. Recall that in an example embodiment, each streammight be connected to one output port for an upstream operator and oneinput port for a downstream operator. When the stream mode is in-line901 (shown in FIG. 9 as the thick arrow), the operator instances (eachof which might be a single thread) connected by the stream are in thesame container (or process). And consequently, the streaming windowsgoing between the output port (of the upstream operator on the stream)and the input port (if the downstream operator on the stream) need notpass through the message queue managed by the container's buffer server.It will be appreciated that such a mode facilitates high throughput ofstreaming windows.

When the stream mode is in-node 902 (shown in FIG. 9 as the arrow withmedium thickness), the streaming windows going between the output port(of an upstream operator on the stream) and the input port (of thedownstream operator on the stream) pass through the message queuemanaged by the container's buffer server. Passing through the messagequeue might entail serialization of tuples into bytes at the output port(of the upstream operator on the stream) and de-serialization of bytesinto tuples at the input port (of the downstream operator on thestream), according to a stream codec (e.g., for stream sockets or othernetwork sockets) such as Kryo. Consequently, the throughput of streamingwindows when the stream-mode is in-node will be lower than thethroughput of streaming windows when the stream-mode is in-line.

When the stream mode is in-rack 903 (shown in FIG. 9 as the thin arrow),the streaming windows going between the output port (for an upstreamoperator on the stream) and the input port (for the downstream operatoron the stream) pass through both the message queue managed by thecontainer's buffer server and a network interface controller (NIC) orother hardware component that connects one server (or other physicalcomputation unit) with another. Consequently, the throughput ofstreaming windows when the stream-mode is in-rack will be significantlylower than the throughput of streaming windows when the stream-mode isin-line or in-node. And when the steam mode is “other” (not shown inFIG. 9), the throughput of streaming windows might be significantlylower than the throughput of streaming windows when the stream-mode isin-line, in-node, and in-rack, in an example embodiment.

In an example embodiment, the software might ignore some or all of thestream modes, treating them as a hints rather than commands. Forexample, a user or code might submit a specification in which allstreams are specified as in-line in order to obtain fast throughput ofstreaming windows, though such an approach would result in a processthat exceeded the capacity of a container. In that event, the softwaremight issue a diagnostic message (e.g., through the CLI or to a logfile) to the user who submitted the application.

FIG. 10 is flowchart diagram that illustrates a process for dynamicallypartitioning operator instances, in accordance with an exampleembodiment. In an example embodiment, this process might be performed bythe STRAM. In an alternative embodiment, some or all of the operationsof this process might be performed by the STRAM Childs or other softwarein the distributed streaming platform.

As depicted in FIG. 10, the software (e.g., the STRAM) determines thatan instance of an operator in a container is creating a bottleneck,based on monitoring results received from container's slave, inoperation 1001. For example, the instance might be an upstream instanceto a downstream instance with two input ports. And the input portconnected to the upstream instance might have significantly lowerthroughput than the other input port. In operation 1002, the softwarepauses the instance of the operator, e.g., after its last checkpointing(e.g., serialization to HDFS). The software then assigns multipleinstances of the operator to the container and connects the instances tothe upstream operators, e.g., using a stream duplicator, and to thedownstream operator, e.g., using a stream merger or a unifier, inoperation 1003. In operation 1004, the software starts the instances ofthe operator (e.g., through the slave), using the last checkpoint and arecovery policy (e.g., at most once, at least once, or exactly once), asexplained in detail above with respect to operation 803 in FIG. 8.

In an example embodiment, a stream codec might be used to split thetuples in a streaming window between multiple instances of the sameoperator that result from static partitioning in the specification ordynamic partitioning at run-time. For example, a hash function might beapplied to a tuple to obtain a hash code and the lower bits of the hashcode might determine which instance of the operator receives the tuple(e.g., if there are two instances the lower bit of the hash code wouldbe sufficient to split the tuples between the instances). It will beappreciated that such an approach (which might be referred to as “stickykey”) differs from a round-robin approach, where the first tuple wouldgo to the first instance, the second tuple would go to the secondinstance, the third tuple would go to the first instance, the fourthtuple would go to the second instance, etc.

In such an example embodiment, the “sticky key” approach might result ina skewed distribution, where one instance of the same operator receivesmany more tuples than the other instances, e.g., 4 tuples received bythe one instance to every 1 tuple received by each of the otherinstances. In that event, the STRAM might lessen the skew by applying atruntime a ratio (e.g., 2:1) of maximum load to minimum load, asconfigured by the user of the application or the application itself(e.g., through the CLI). In that event, the one instance receiving moretuples would receive at most 2 tuples for every 1 instance received byeach of the other instances.

FIG. 11A is a diagram showing the use of dynamic partitioning ofinstances to lessen skew resulting from “sticky key” assignment oftuples, in accordance with an example embodiment. In this exampleembodiment, the logical plan 1101 is translated into an execution plan1102, in which there are three instances of operator 1, namely, 1 a, 1b, and 1 c. Because of the “sticky key” assignment of tuples, instance 1c is emitting 60% of the tuples received by the lone instance ofoperator 2 and instances 1 a and 1 b are each emitting 20% of the totalnumber of tuples received by the lone instance of operator 2. Such askew might be the result of spiking caused by a hash function tied todirectly or indirectly to a geographic location (e.g., the IP address ofusers) in another time zone; e.g., a spike that results from Internetusers waking up in the morning in Russia. If the skew rule (e.g., asconfigured by the user) is that no instance shall emit more than 50% ofthe total number of tuples received by another instance, the STRAM mightenforce the skew rule through an execution plan 1103 that mergesinstance 1 a and 1 b into a single instance (1 a+ 1 b) and splitsinstance 1 c into two instances, 1 ca and 1 cb. It will be appreciatedthat this execution plan preserves the partition count (e.g., threeinstances of operator 1) in the original execution plan 1102.

FIG. 11B is a diagram showing the use of a unifier instance to lessenskew resulting from “sticky key” assignment of tuples, in accordancewith an example embodiment. Here again, the logical plan 1111 istranslated into an execution plan 1112, in which there are threeinstances of operator 1, namely, 1 a, 1 b, and 1 c. Because of the“sticky key” assignment of tuples, instance 1 c is emitting 60% of thetuples received by the lone instance of operator 2 and instances 1 a and1 b are each emitting 20% of the total number of tuples received by thelone instance of operator 2. If the skew rule is again that no instanceshall emit more than 50% of the total number of tuples received byanother instance, the STRAM might enforce the skew rule through anexecution plan 1113 that splits instance 1 c into two instances, 1 caand 1 cb, and later merges the streams from those instances using aunifier that might include special code for handling spikes (e.g., aleaky bucket algorithm). It will be appreciated that this execution plandoes not preserve the partition count (e.g., three instances of operator1) in the original execution plan 1112.

FIG. 11C is a diagram showing the use of cascading unifiers for morelinear scaling, in accordance with an example embodiment. In an example,the logical plan 1121 is translated into an execution plan 1122, inwhich there are four instances of the upstream operator (uopr1, uopr2,uopr3, and uopr4) and one instance of the downstream operator (dopr),where N is the number of instances of the upstream operator and M is thenumber of instances of the downstream operator. However, in executionplan 1122, all four of the upstream operators emit streams that passthrough a NIC to another container, where a unifier with special codemerges the streams for the downstream operator. Such an execution planmight result in a bottleneck forming at the NIC and/or at the containerin which the unifier runs. To prevent such a bottleneck, the STRAM mightuse cascading unifiers consisting of two or more levels of unifiers. Inexecution plan 1123, there are two levels (K equals 2); the first levelcontains two containers, each with its own unifier, and the second levelcontains one container with one unifier.

FIG. 12 is a diagram illustrating a stream in a message queue managed bya container's buffer server, in accordance with an example embodiment.In an example embodiment, each container might be a multi-threadedprocess with one thread for the slave, one thread for each instance ofan operator, and one thread for each buffer server. As depicted in FIG.12, the message queue 1201 is a FIFO (not priority) queue, where theoldest complete streaming window in the stream is window n at the bottomof the queue and the newest complete streaming window in the stream iswindow n+2 towards the top. In an example embodiment, message queue 1201might be based on a publisher-subscriber model, where one output port(writer port) writes streaming windows for a stream into the messagequeue and multiple input ports (read port1, read port2, and read port3)read from the message queue by subscribing to the stream from aparticular streaming window “onwards” (e.g., in term of n incrementing).Thus, in message queue 1201, read port3 might be subscribing to thestream from streaming window n onwards (e.g., n, n+1, n+2, n+3, etc.),read port2 might be subscribing to the stream from streaming window n+1onwards (e.g., n+1, n +2, n+3, etc.), and read port1 might besubscribing to the stream from streaming window n+3 onwards.

In an example embodiment, security for the distributed streamingplatform might be provided by Kerberos, where the access points are theSTRAM and each of the buffer servers. In that embodiment, the STRAMmight obtain a security token and pass it to the STRAM Child (e.g., athread), which, in turn, passes it to the buffer server (e.g., also athread) that it monitors and controls in their shared container (orprocess). The buffer server could then use the security token to verifythe security of any new connection to the container. Also, in an exampleembodiment, security for the distributed streaming platform's graphicaluser interfaces (GUIs) might be provided by Simple and Protected GSSAPINegotiation Mechanism (SPNEGO).

In an example embodiment, a reservoir buffer (e.g., a thread) associatedwith an instance of an operator might be used to synchronize streamingwindows for operator instances with multiple input ports. In an exampleembodiment, the reservoir buffer might monitor the input ports todetermine when a begin window tuple (e.g., a control tuple) with a newwindow identifier has been received by one of the input ports. Thereservoir buffer might then emit a begin window tuple with that windowidentifier on the output port for the instance (e.g., using thecontainer's message queue or another FIFO queue), in an exampleembodiment. But the reservoir buffer might emit an end window tuple withthat window identifier on the output port for the instance (e.g., usingthe container's message queue or another FIFO queue) only after thereservoir buffer determines that an end window tuple with thatidentifier has been received by all of the input ports for the instance.It will be appreciated that in such an example embodiment, theinstance's propagation of a begin window tuple (and the processing ofthe data tuples that follow the begin window tuple) is non-blocking withrespect to the instance, whereas the instance's propagation of an endwindow tuple is blocking with respect to the instance (except, in anexample embodiment, when performing the operations in a recovery policyas described below). Further, the completion of a streaming window in aninstance of an operator (e.g., propagation of an end window through aninstance, in an example embodiment) only occurs after all upstreaminstances have finished processing the streaming window. That is, thewindow identifier of the streaming window in an upstream instance isgreater than or equal to the window identifier of the streaming windowin the instance and the window identifier of the streaming window in adownstream instance is less than or equal to the window identifier ofthe streaming window in the instance. Also, in an example embodiment,the reservoir buffer might merge data tuples received on multiple inputports from different instances of the same upstream operator into asingle queue (e.g., using the container's message queue or another FIFOqueue), through a “first come-first served” approach to aggregation.This is illustrated in the following figure.

FIG. 13 is a diagram illustrating the flow of tuples in the streams ofan operator instance with two input ports and one output port, inaccordance with an example embodiment. As shown in this figure, thefirst input port (i1) receives a stream1 (1301) whose earliest tuplesare bw1 (begin window 1) and t11 and whose latest tuple is ew1 (e.g.,end window 1). The tuples bw1 and t11 arrive before any tuples fromstream2 (1302), which is received by the second input port (i2). Theearliest tuples in stream2 (1302) are bw2 (begin window 2) and t21 andthe latest tuple in this stream is ew2 (end word 2). In an exampleembodiment, the operator processes tuples using a “first come-firstserved” approach resulting in a FIFO message queue 1303 for the outputport (o1) where all of the tuples from the second stream are enqueued(e.g., processed) before the last three tuples of the first stream, eventhough it arrived first. Note that during the processing, the operatorremoved control tuples bw1, bw2, ew1, and ew2 and inserted in theirstead control tuples bw and ew. In an example embodiment, the operatorin this figure might be used for aggregating (or merging) streams fromtwo instances of the same operator.

FIG. 14A is diagram showing the interactions between a STRAM and a STRAMChild, in an example embodiment. As shown in this figure, the STRAM 1401is the master of the STRAM Child 1402, its slave. In turn, the STRAMChild 1402 is the master of the instances, namely, instance 1403(Instance A) and instance 1404 (Instance B). Additionally, the STRAMChild 1402 is the master of the Buffer Server 1405, which manages amessage queue (FIFO, not priority) of streaming windows. Each slave(e.g., STRAM Child 1402 or instance 1404, respectively) reportsmonitoring data to its master (e.g., STRAM 1401 or STRAM Child 1402,respectively), which then makes dynamic adjustments which might beeffected by the slave (e.g., STRAM Child 1402 or instance 1404,respectively). Also, as shown in this figure, STRAM Child 1402, instance1403 (Instance A) and instance 1404 (Instance B), and Buffer Server 1405might each be a single thread executing in a multithreaded process (orcontainer), in an example embodiment.

FIG. 14B is a sequence diagram showing the initiation of a streamingapplication, in accordance with an example embodiment. As depicted inthis figure, a streaming application is initiated by a command (e.g.,from a user or a script identifying the location of the application'sfiles in a file system such as HDFS) received at a command lineinterface (CLI), which might be a wrapper for a web service, in anexample embodiment. The CLI communicates the command to a resourcemanager (RM), which might be a YARN Resource Manager, in operation 1.The RM then launches a streaming application manager (STRAM) in acontainer in operation 2, to start the application. The STRAM compilesthe application (which includes a logical plan), produces a physicalplan (from the logical plan) that partitions the operators intoinstances, obtains the containers for the physical plan from the RM, anddetermines an execution plan based on the physical plan and containersobtained. The STRAM then executes the execution plan, which creates oneStram Child in each container and which assigns the instances of theoperators to the containers, in operation 3. Two input adapters thenstart the streams that feed the instances in the containers. Some of thestreams are inline streams between instances in the same container.These streams avoid the overhead of a message queue managed by a bufferserver. Some of the streams are node-local streams between instances indifferent containers on the same server. These streams pass though amessage queue managed by a buffer server, but avoid the overhead ofserver NICs. And some of the streams are between instances on differentservers, which incur the overhead of both the message queue managed bybuffer server and a server NIC. The computations performed by theinstances culminate in a stream that is output by a single outputadapter, e.g., to a GUI displayed by a console or a file in a filesystem (e.g., HDFS).

FIG. 14C is a diagram showing the ongoing execution of a streamingapplication, in accordance with an example embodiment. As shown in thisfigure, an application 1411 communicates through a CLI with a STRAM1413, that monitors and controls threes slaves (e.g., STRAM Child 1414,STRAM Child 1415, and STRAM Child 1416). In an example embodiment, eachof the slaves executes in its container. As shown in the figure, aserver in a networked cluster might have multiple containers. In orderto make dynamic adjustments to the application through the slaves, theSTRAM 1413 obtains resources (e.g., containers) from Resource Manager1412. STRAM Child 1414 monitors and controls an input adapter, whichreceives a stream of streaming data from a source over the Internet andinserts control tuples into the streaming data, in an exampleembodiment. STRAM Child 1415 monitors and controls instances thatperform computations on the streaming data. And STRAM Child 1416monitors and controls an output adapter that removes the insertedcontrol tuples and outputs the resultant streaming data to theapplication's display, in an example embodiment.

FIG. 15A is a logical plan for a streaming application that originatesin a stock ticker, in accordance with an example embodiment. Noted againfor clarity, stock ticker data is only one example and other type ofdata that is not financial in nature can also be analyzed. Now, as shownin this figure, the logical plan includes operator 1 (Stock Tick Input)that inputs streams of data that include time, price, and volume intothe application from an external source, e.g., a website such as Yahoo!Finance. Operator 1 (Stock Tick Input) transmits the volume stream tooperator 2 (Daily Volume), which computes a stream of daily-volume dataand transmits it to operator 3 (Quote), which also receives the timestream and the price stream from operator 1 (Stock Tick Input). Operator3 (Quote) computes a stream of quote data and transmits it to operator 4(Console), e.g., for display in a GUI. The GUI can be of any type ofdevice, such as a desktop computer, a laptop computer, a portabledevice, a smartphone, a tablet computer, or any device that can present,display or render the data for the GUI.

Operator 1 (Stock Tick Input) also transmits the price stream tooperator 5 (High Low), which computes a stream of high-low price dataand transmits it to operator 7 (Chart). Operator 1 (Stock Tick Input)also transmits the volume stream to operator 6 (Minute Vol), whichcomputes a stream of volume-per-minute data and transmits it to operator7 (Chart). Operator 7 (Chart) computes a stream of chart data andtransmits it to operator 8 (Console), e.g., for display in a GUI.Operator 1 (Stock Tick Input) also transmits the price stream tooperator 9 (SMA or simple moving average), which computes a stream ofsma-price data and transmits it to operator 10 (Console), e.g., fordisplay in a GUI.

FIG. 15B is an execution plan for a streaming application thatoriginates in a stock ticker, in accordance with an example embodiment.This figure shows an execution plan for the logical plan described inFIG. 15A. As depicted in FIG. 15B, the STRAM is operating in its owncontainer at the bottom left of the figure. Pursuant to the executionplan, the STRAM has assigned instance 1 (Stock Tick Input) to its owncontainer, where it is monitored by a STRAM Child, which reports itsresults to the STRAM for dynamic adjustment (e.g., through the STRAMChild, which, in turn, controls the instances and the buffer server).Also pursuant to the execution plan, the STRAM has assigned instance 2(Daily Volume), instance 3 (Quote), and instance 4 (Console) to onecontainer, where they are jointly monitored by a STRAM Child, whichreports its results to the STRAM for dynamic adjustment. The STRAM hasassigned instance 5 (High Low), instance 6 (Minute Vol), instance 7(Chart), and instance 8 (Console), where they are jointly monitored by aSTRAM Child, which reports its results to the STRAM for dynamicadjustment. And the STRAM has instance 9 (SMA), and instance 10(Console) to one container, where they are jointly monitored by a STRAMChild, which reports its results to the STRAM for dynamic adjustment. Itwill be appreciated that the execution plan shown in FIG. 15B makes useof few inter-container streams, since such streams incur overheadassociated with the transmission of the stream through the upstreamcontainer's message queue managed (e.g., managed by a buffer server).Inter-server streams incur an even greater overhead associated with thetransmission of the stream through NICs.

In an example embodiment, operator instances in physical plans andexecution plans might be identified as integers, rather than strings,chars, etc., for purposes of performance efficiency.

FIGS. 16A to 16E illustrate an application dashboard in a graphical userinterface (GUI) for a distributed streaming platform, in accordance withan example embodiment. As depicted in FIG. 16A, a dashboard displayed bythe distributed streaming platform might include a GUI view 1601 thatincludes a list 1602 of the application instances being run by thedistributed streaming platform. It will be appreciated that thedistributed streaming platform might support multiple tenants (e.g.,application instances), in an example embodiment. GUI view 1601 alsoincludes GUI controls 1603, 1604, and 1605. If a user checks thecheckbox next to one of the application instances in list 1602 andclicks control 1603 (labeled “inspect”), the application dashboard mightdisplay a view that shows data for that application instance, such asthe view shown in following figure. If a user checks the checkbox nextto one of the application instances in list 1602 and clicks control 1604(labeled “kill”), the application dashboard might stop the applicationinstance, if it is running. And if a user checks the checkbox next toone of the application instances in list 1602 and clicks control 1605(labeled “relaunch”), the application dashboard might re-launch theapplication instance, if it has been killed.

FIG. 16B shows a GUI view 1611 that might be displayed when a userenters a command to inspect an application instance, e.g., using control1603 in FIG. 16A. The GUI view 1611 displays data for an applicationinstance identified by application name 1612 (whose value is“com/mailhartech/demos/chart/YahooFinanceApplication.class”). The datadisplayed for the application includes the last window identifier 1613(whose value is 8860), the number 1614 of containers (whose value is 5)and the period 1615 of time that the application has been running (3days, 10 hours, 3 minutes). GUI view 1611 also displays a list 1616 ofthe 5 containers used by the application, a chart 1617 of the operatorsused by the application, and graph 1618 of metrics related to theapplication. As indicated by the GUI controls in the toolbar 1619 in GUIview 1611, the application dashboard can be customized by the userthrough the addition of new widgets to an existing dashboard or thecreation of a new dashboard. FIG. 16C shows a close-up diagram of thechart 1617 and the graph 1618 in FIG. 16B.

FIG. 16D shows a GUI view 1621 that might be displayed when a userenters a command to inspect an operator instance, e.g., by clicking onan operator instance in FIG. 16B. GUI view 1621 includes table 1622 anda graph 1627. The table 1622 might include a name 1623 for the operatorinstance (whose value is “UniqueURLCounter”), a container identifier1624 (whose value is 7), a current window 1625 (whose value is 1046),and a recovery window 1626 (whose value is 999). The graph 1627 displaysperformance metrics for the operator instance, e.g., Emitted/sec,Processed/sec, Percentage of CPU, and Latency. FIG. 16E is a close-updiagram of table 1622. The table 1622 includes a list of ports whichshows an input port 1628 with tuples named “data” and an output port1629 with tuples named “count”. The table 1622 also includes a recordingtable 1630, which facilitates debugging as explained further below.

FIGS. 17A to 17C illustrate GUI views for debugging an applicationrunning on a distributed streaming platform, in accordance with anexample embodiment. FIG. 17A includes a GUI view 1701 that might bedisplayed when a user selects an operator from the list 1617 ofoperators shown in FIG. 16C. As shown in FIG. 17A, the selection of anoperator instance results in the display of two GUI controls, a control1702 labeled “inspect” that allows a user to see further data regardingthe selected instance and a control 1703 labeled “start recording” thatallows a user to record the data related to the processing of tuples bythe selected instance.

FIG. 17A also includes a GUI view 1704 which might be displayed (e.g.,as part of table 22 in FIG. 16E) when a user clicks control 1703 in GUIview 1701. GUI view 104 includes three controls: (a) a control 1705labeled “view tuples”; (b) a control 1706 labeled “stop recording”; and(c) a control 1707 labeled “refresh list”. If a user clicks on thecontrol labeled 1705, the distributing steaming platform might displaythe GUI view 1708 shown in FIG. 17B.

GUI view 1708 is a tuple viewer associated with a recording whose name1709 is “container_1370542662205_0007_01_000007_3_1370896978891”. GUIview 1708 also includes a window identifier 1710 (whose value is 8816)that shows the streaming window that is the source of the tuples shownin the GUI view and processed by the selected instance (e.g., “operator3” as shown at the top left of the view). The tuples themselves areshown as a scrollable stream 1711, with the earliest tuple at the top ofthe stream and the latest tuple at the bottom of the stream. Tuple 1712is an input tuple (“data” in terms of table 1622) whose identifyingnumber is 5804 and whose value 1713 is a URL, namely,“http://twcm.me/MLwbd”. Tuple 1714 is an output tuple (“count” in termsof table 1622) whose identifying number is 5808 and whose value 1715includes “http://twcm.me/MILwdb”: “100”, which is a count of the numberof times that the URL “http://twcm.me/MLwbd” has been seen. FIG. 17Cshows GUI view 1704 after a user has clicked control 1706 to stop therecording of data related to tuples processed by the selected instance.

FIG. 18 is a flowchart diagram that illustrates a process for combiningtwo operator instances connected by a stream in a container, inaccordance with an example embodiment. In an example embodiment, thisprocess might be performed by the Streaming Application Master (STRAM).In the same or an alternative embodiment, some or all of the operationsof this process might be performed by a STRAM child (e.g., a slave) orother software in the distributed streaming platform.

As depicted in FIG. 18, the software (e.g., the STRAM) launches areal-time streaming application that runs on a distributed streamingplatform, in operation 1801. In an example embodiment, the real-timestreaming application might be structured as a directed acyclic graph(DAG) with instances of operators as nodes and streams as edges betweennodes, as described earlier. In operation 1802, the software receives anindication that a stream is I/O bound, where a stream connects oneoperator instance to another operator instance in a single containerprovided by the distributed streaming platform. In an exampleembodiment, the indication is a platform measurement as to resource use,e.g., throughput of streaming windows or tuples for the stream. Or theindication might be a platform measurement as to a pre-defined hint, asdescribed in further detail below. Then in operation 1803, the softwaretransmits the platform measurement to the real-time streamingapplication (e.g., through an API exposed by the distributed streamingplatform) and receives a request (e.g., a request setting an attributeof a stream) from the real-time streaming application to combine theoperator instances connected by the stream into a single operatorinstance. And in operation 1804, the software creates a single operatorinstance (e.g., through compiler in-lining) and re-initiates the stream(e.g., using a recovery policy such as at least once, at most once,exactly once, etc.).

In an example embodiment, each of the operations in this process mightbe executed in real time or near real time rather than offline.Moreover, some of the operations described in the process (e.g., theoperations following the original launch of the real-time streamingapplication) might be continuous or non-stop operations, in an exampleembodiment.

In operation 1802, the software receives an indication that a stream isI/O bound. Recall that in an example embodiment, an operator instancemight be a thread and a server buffer managing a message queue forstream might be a thread. It will be appreciated that the term “I/Obound” is a term of art in the field of computer science and refers to acondition where the time period to complete a computation (e.g., theoperations performed by a thread) is primarily determined by time spentwaiting for read/write operations to be completed, e.g., reading/writingto storage (e.g., to volatile storage such as main memory or topersistent storage such as a hard disk or flash memory). By contrast,the term “CPU bound” refers to a condition where the time period tocomplete a computation (e.g., the operations performed by a thread) isprimarily determined by time spent processing data. It will beappreciated that a stream might become I/O bound, for example, if thestreaming windows of tuples processed by a thread involved in the stream(e.g., an operator instance or a server buffer) spill over from mainmemory to persistent storage. In an example embodiment, the softwaremight determine that a stream is I/O bound if throughput increases as aresult of a partition of one or both of the stream's operator instances,e.g., when the software performs automated sensitivity analysis withrespect to partitioning and throughput. It will be appreciated that suchpartitioning might be avoided by combining the operator instancesconnected by a stream into a single operator instance, which, in turn,might free up resources such as containers.

In operation 1803, the software from the real-time streaming applicationreceives a request to combine the operator instances connected by thestream into a single operator instance. In an example embodiment, therequest might involve the setting of an attribute on the stream, e.g.,STREAM_LOCALITY=ThreadLocal. In the same or other embodiments, therequest might take the form of a change to the stream mode as describedearlier, e.g., from in-node to in-line or from in-rack to in-line. InFIG. 18, the request occurs at run-time, e.g., after the launch of thereal-time streaming application. Alternatively, the request might occurprior to launch, in the logical plan (e.g., the specification) for thereal-time streaming application.

FIG. 19 is a sequence diagram that shows the components involved incombining two operator instances connected by a stream in a container,in accordance with an example embodiment. It will be appreciated thatthis figure involves operations similar to those depicted in FIG. 18. Asshown in FIG. 19, there might be four components involved in combiningtwo operator instances connected by a stream in a container: (a) areal-time streaming application; (b) a STRAM; (c) a STRAM child; and (d)the operator instances. In operation 1, which is earliest in time, theSTRAM sets the stream mode between two operator instances connected by astream in a container to be in-node, e.g., per the specification for thereal-time streaming application. In operation 2, the STRAM assigns theoperator instances to the containers, e.g., per a partition in thespecification, and launches the application. In operations 3, a STRAMchild monitors a throughput statistic (e.g., throughput of streamingwindows or tuples) for a stream between two in-node operator instancesin a single container. In operation 4, the STRAM receives the results ofthe monitoring (including the throughput statistic) from the STRAM childand, in operation 5, the real-time streaming application obtains theresults using an API exposed by the distributed streaming platform.Based on the throughput statistic for the stream (e.g., which indicatesthat the stream is I/O bound), the real-time streaming application usesthe API to request that the stream mode be made in-line (e.g., that thestream's locality be made “ThreadLocal”), in operation 6. In an exampleembodiment, such a stream mode will result in the two operator instancesconnected by the stream being combined into a single operator instance.Then in operation 7, the STRAM makes the stream in-line (e.g., throughcompiler in-lining) and re-initiates the stream, e.g., using a recoverypolicy.

It will be appreciated that in FIG. 19, a throughput statistic providesthe indication that a stream is I/O bound. However, in the same or analternative embodiment, the indication might involve (s) a platformmeasurement of another statistic or (b) a platform measurement as to apre-defined hint, e.g., number of hash table/map keys.

FIG. 20 is a diagram showing the combination of two operator instancesconnected by a stream in a container, in accordance with an exampleembodiment. As depicted in this figure, operator instance 2002 (labeledOperator A) and operator instance 2003 (labeled Operator B) areconnected by a stream in a single container 2001 on the left side of thearrow before combination. The stream is associated with a message queue2004 (a main-memory buffer backed by persistent storage) managed by abuffer server (which might be a thread in an example embodiment) thatreceives streaming windows of tuples from Operator A and transmits themin order to Operator B. Following combination, single container 2001, onthe right side of the arrow, contains only one operator instance 2005(labeled Operator A-Operator B), which does not use the message queue2004. In an example embodiment, the combination of the two operatorinstances into a single operator instance might be done by pausing thestream between the two operator instances, in-lining the programinstructions for the two operator instances, recompiling, andre-initiating the stream using a recovery policy.

FIG. 21 is a diagram showing the call stacks for a combined operatorinstance resulting from the combination of two operator instancesconnected by a stream in a container, in accordance with an exampleembodiment. As depicted in this figure, call stack 2101A is a call stackfor a container with a STRAM child, a buffer server, an operatorinstance 2102 (labeled Operator A), and an operator instance 2103(labeled Operator B) before combination of the operator instances. In anexample embodiment, the container might be a process, the STRAM childmight be a thread, the buffer server might be a thread, and eachoperator instance might be a thread. In an example embodiment, callstack 2101A might include container code 2104, container data 2105, andcontainer files 2106. Additionally, call stack 2101A might also includethread registers, a thread stack, and thread code for each of the fourthreads: the STRAM child, the buffer server, operator instance 2102, andoperator instance 2103. Following combination of operator instance 2102and operator instance 2103, call stack 2101B includes thread registers,a thread stack, and thread code for a single operator instance, operatorinstance 2107 (labeled Operator A-B). It will be appreciated that theoverhead (e.g., call and/or return time for each execution of a thread)associated with call stack 2101B is less than the overhead associatedwith call stack 2101A, since there is one less operator instance in theformer call stack.

FIG. 22 is a flowchart diagram that illustrates a process for creating adynamic partition using a pre-defined hint, in accordance with anexample embodiment. In an example embodiment, this process might beperformed by the Streaming Application Master (STRAM). In the same or analternative embodiment, some or all of the operations of this processmight be performed by a STRAM child (e.g., a slave) or other software inthe distributed streaming platform.

As depicted in FIG. 22, the software (e.g., the STRAM) receives areal-time streaming application that runs on a distributed streamingplatform, in operation 2201. In an example embodiment, the real-timestreaming application is structured as a directed acyclic graph (DAG)with instances of operators as nodes and streams as edges between nodes.The real-time streaming application is associated with a pre-definedhint that is a key-value pair (e.g., the number of entries in a hashtable/map). In operation 2202, the software launches the real-timestreaming application by initiating streams and assigning instances ofoperators to containers provided by the distributed streaming platform.In operation 2203, the software reads the value for a pre-defined hint(e.g., the number of entries in hash table/map) and transmits the valueto the real-time streaming application through an applicationprogramming interface (API) exposed by the distributed streamingplatform. Then in operation 2204, the software receives a request fromthe real-time streaming application through the API to make a dynamicadjustment (e.g., partition an instance of an operator reading fromand/or writing to a hash table/map into multiple instances of theoperator). And in operation 2205, the software makes the dynamicadjustment and initiates/re-initiates the corresponding streams using arecovery policy, as described above.

Here again, each of the operations in this process might be executed inreal time or near real time rather than offline, in an exampleembodiment. Moreover, some of the operations described in the process(e.g., the operations following the original launch of the real-timestreaming application) might be continuous or non-stop operations, in anexample embodiment.

The process described above uses as an example a key-value pair that isnumber of entries in a hash table/map. This example is not meant to belimiting. For example, in the same or other embodiments, the key-valuepair might be a count associated with another data structure, e.g., thenumber of entries in a linked list.

In operation 2205, the software makes a dynamic adjustment, e.g.,partitioning an instance of an operator reading from and/or writing to ahash table/map into multiple instances (e.g., 3 instances) of theoperator. In an example embodiment, this dynamic partitioning mightresult in the creation of multiple instances (e.g., 3 instances) of thehash table/map, for example, if the hash table/map is local variable(e.g., on the thread stack) for the operator instance. Or the dynamicpartitioning might result in no new additional instances of the hashtable/map, for example, if the hash table/map is a global variable(e.g., container data) for the operator instance. In an exampleembodiment, the dynamic adjustment might not involve partitioning anoperator instance. Rather, the dynamic adjustment might involvesetting/unsetting an operator attribute (e.g., a customization of theoperational behavior of an operator). Or the dynamic adjustment mightinvolve setting or unsetting an operator property (e.g., a customizationof the formal definition of an operator). Also, in an exampleembodiment, the dynamic adjustment might involve setting the localityattribute of a stream to ThreadLocal to combine two operators into one.Or the dynamic adjustment might involve flushing a hash table/map todisk.

FIG. 23 is a sequence diagram that shows the components involved increating a dynamic partition using a pre-defined hint, in accordancewith an example embodiment. It will be appreciated that this figureinvolves operations similar to those depicted in FIG. 22. As shown inFIG. 23, there might be four components involved in creating a dynamicpartition using a pre- defined hint: (a) a real-time streamingapplication; (b) a STRAM; (c) a STRAM child; and (d) the operatorinstances. In operation 1, which is earliest in time, the STRAM receivesa specification for a real-time streaming application which defines ahint that is key-value pair, e.g., the number of keys in a hashtable/map used by an operator. In operation 2, the STRAM assignsoperator instances to containers, e.g., per a static partition in thespecification, and launches the real-time streaming application. Inoperation 3, a STRAM child monitors values of the hint, e.g., the numberof keys in hash table/map used by operator instance. In operation 4, theSTRAM receives the results of the monitoring (including the hint, e.g.,the number of keys in hash table/map) from the STRAM child and, inoperation 5, the real-time streaming application obtains the resultsusing an API exposed by the distributed streaming platform. Based on thehint (e.g., the number of keys in hash table/map), the real-timestreaming application uses the API to request that a dynamic partitionto increase the number of operator instances (and the number of hashtables/maps, in an example embodiment), in operation 6. For example, thereal-time streaming application might include logic (e.g., code) thatrequests a dynamic partition to increase the number of instances of anoperator if the number of keys exceeds one million. Then in operation 7,the STRAM receives the request and assigns more instances of theoperator to the original or a new container and initiates/re-initiatesthe corresponding streams as discussed above.

Here again, in an example embodiment, the dynamic partitioning inoperation 7 might result in the creation of multiple instances (e.g., 3instances) of the hash table/map, for example, if the hash table/map islocal variable (e.g., on the thread stack) for the operator instance. Orthe dynamic partitioning might result in no new additional instances ofthe hash table/map, for example, if the hash table/map is a globalvariable (e.g., container data) for the operator instance.

FIG. 24 is a flowchart diagram that illustrates a process using ascalable local cache in a container and a pre-defined hint, inaccordance with an example embodiment. In an example embodiment, thisprocess might be performed by the Streaming Application Master (STRAM).In the same or an alternative embodiment, some or all of the operationsof this process might be performed by a STRAM child (e.g., a slave) orother software in the distributed streaming platform.

As depicted in FIG. 24, the software (e.g., the STRAM) receives areal-time streaming application that runs on a distributed streamingplatform, in operation 2401. The real-time streaming application isstructured as a directed acyclic graph (DAG) with instances of operatorsas nodes and streams as edges between nodes. In an example embodiment,multiple (e.g., partitioned) instances of the same operator access thesame database. In operation 2402, the software receives a pre-definedhint associated with the real-time steaming application, where thepre-defined hint sets a maximum period of time (e.g., approximately 8hours) for local caching of a result from a query of the database byeach of the multiple instances. Alternatively, the maximum period oftime for local caching might be a default setting for the real-timestreaming application. In operation 2403, the software launches thereal-time streaming application by assigning instances of operators tocontainers provided by the distributed streaming platform and initiatingstreams. In an example embodiment, each container is associated with alocal cache which is resizable upward or downward (e.g., fromapproximately 4 GB). Then in operation 2404, the software monitors aperformance statistic (e.g., throughput such as number of bytes read perms, number of bytes written per ms, number of keys read per ms, numberof keys written per ms, etc.) for accesses to the database by each ofthe multiple instances and transmits the results of the monitoring tothe real-time streaming application through an application programminginterface (API) exposed by the distributed streaming platform. In anexample embodiment, the number of keys read/written per ms might pertainto the keys in a key-value table/map (e.g., a social security number orSSN used as a key for a person's address). In operation 2405, thesoftware receives a request from the real-time streaming applicationthrough the API to make a dynamic adjustment that increases the maximumperiod of time (e.g., to approximately 24 hours or more) for localcaching of a result from a query of the database by each of multipleinstances. And in operation 2406, the software makes the dynamicadjustment.

Here again, each of the operations in this process might be executed inreal time or near real time rather than offline, in an exampleembodiment. Moreover, some of the operations described in the process(e.g., the operations following the original launch of the real-timestreaming application) might be continuous or non-stop operations, in anexample embodiment.

In an example embodiment, YARN might be used to create the local cachein each container, on an as-needed basis. It will be appreciated thatsuch a local cache (e.g., a compute-local memory cache) differs from thetraditional implementation of Memcached, which employs a client-serverrelationship with a relatively small number of servers providing memorycaching services to a relatively large number of clients.

FIG. 25 is a sequence diagram that shows the components involved in aprocess using a scalable local cache in a container and a pre-definedhint, in accordance with an example embodiment. It will be appreciatedthat this figure involves operations similar to those depicted in FIG.24. As shown in FIG. 25, there might be four components involved in aprocess using a scalable local cache in a container and a pre-definedhint: (a) a real-time streaming application; (b) a STRAM; (c) a STRAMchild; and (d) the operator instances. In operation 1, which is earliestin time, the STRAM receives a specification which defines a hint, e.g.,maximum time in local cache. In operation 2, the STRAM assigns operatorinstances to containers, e.g., per a static partition in thespecification, and launches the real-time streaming application. Inoperation 3, a STRAM child monitors a throughput statistic (e.g., numberof keys read/written per ms) by an operator instance that reads/writesdata to persistent storage (e.g., a database shared with otherpartitioned instances of the operator) using a local cache controlled bythe maximum time. In operation 4, the STRAM receives the results of themonitoring (including a throughput statistic, e.g., number of keysread/written per ms) from the STRAM child and, in operation 5, thereal-time streaming application obtains the results using an API exposedby the distributed streaming platform. Based on the hint (including thethroughput statistic, e.g., number of keys read/written per ms), thereal-time streaming application uses the API to request an increasedmaximum time in local cache, in operation 6. For example, the real-timestreaming application might include logic (e.g., code) that requests anincreased time in local cache if the number of keys read/written per ms(e.g., from the database) is greater than ten thousand keys per ms. Thenin operation 7, the STRAM receives the request and increases the maximumtime in local cache.

FIG. 26 is a diagram showing a scalable local cache in a container, inaccordance with an example embodiment. As depicted in this figure, aYARN container 2601 includes two allocations of volatile memory (e.g.,main memory): a local cache 2602 created with YARN and a message queue2602 controlled by a buffer server (e.g., a thread). The container alsoincludes a stream with two partitioned instances of an operator,Instance A1 and A2, which receive streaming windows from an inputadapter and which transmit streaming windows to a unifier. In an exampleembodiment, each of the operator instances might read/write data to ashared persistent database (not shown) using local cache 2602. It willbe appreciated that the cache coherency for the local cache is relatedto the maximum time in local cache. That is to say, as the maximum timein local cache increases, so does the probability of a stale value beingin the local cache.

FIG. 27 is a flowchart diagram that illustrates a process usingpartitionable unifiers, in accordance with an example embodiment. In anexample embodiment, this process might be performed by the StreamingApplication Master (STRAM). In the same or an alternative embodiment,some or all of the operations of this process might be performed by aSTRAM child (e.g., a slave) or other software in the distributedstreaming platform.

As depicted in FIG. 27, the software (e.g., the STRAM) receives areal-time streaming application that runs on distributed streamingplatform, in operation 2701. The real-time streaming application isstructured as directed acyclic graph (DAG) with operators as nodes andstreams as edges between nodes. In an example embodiment, the real-timestreaming application includes an operator that receives values (e.g.,values in key-value table/map), counts values that are unique (ordistinct), and emits the unique values in a stream. In operation 2702,the software partitions (e.g., statically in a specification for thereal-time streaming application or dynamically based on monitoring) theoperator into multiple partitioned instances. In an example embodiment,the partitioning results in a round-robin distribution of values to themultiple partitioned instances. In operation 2703, the software assignseach unique value emitting from a partitioned instance to one of a groupof unifiers according to a pre-defined scheme (e.g., alphabetic/ASCII ornumeric). In an example embodiment, each partitionable unifier creates acount of the unique values received by that partitionable unifier. Thenin operation 2704, the software transmits the counts from each of thepartitionable unifiers to a downstream instance of an operator thataggregates the counts into a sum of unique values. And in operation2705, the software causes the sum of unique values to be displayed in agraphical user interface (GUI) such as a dashboard.

Here again, each of the operations in this process might be executed inreal time or near real time rather than offline, in an exampleembodiment. Moreover, some of the operations described in the process(e.g., the operations following the original launch of the real-timestreaming application) might be continuous or non-stop operations, in anexample embodiment.

FIG. 28A is a diagram showing three use cases that do not usepartitionable unifiers, in accordance with example embodiments. In usecase 1 shown in this figure, no static or dynamic partition is used. Soall of the values (e.g., alphabetic identifiers labeled “A-Z” in thefigure, such as a series of surnames: Adams, Smith, Jones, Smith,Williams, Jones, . . . , Smith) stream from an input (e.g., an inputadapter labeled “Input”) to a single operator instance, labeled Inst. Itwill be appreciated that an accurate count of unique (or distinct)values can be obtained by a single operator instance. However, there isno parallelism (e.g., multiple instances of the same operator executingin parallel). And consequently, use case 1 does not scale to handlelarge series of values.

Use case 2 shown in FIG. 28A solves the scalability problem by usingmultiple instances (labeled “Inst 1”, “Inst 2”, and “Inst 3”) of thesame operator executing in parallel which transmit counts of uniquevalues to a downstream operator (e.g., a unifier labeled “Unif”) thatsums the counts. In an example embodiment, the values are distributedbetween the three operator instances using a round-robin scheme thatresults in each operator instance receiving approximately 33.3% of thevalues. It will be appreciated that an accurate sum of unique valuesmight not be obtained in this use case. For example, if the valuesinclude three values of the surname Smith and each of these values isdistributed by the round-robin scheme to a different operator instance,this value will be reported as unique (or distinct) even though it isnot.

Use case 3 shown in FIG. 28A also solves the scalability problem byusing multiple instances (Inst 1, Inst 2, and Inst 3) of the sameoperator executing in parallel. In an example embodiment, the values aredistributed between the three operator instances using a sticky-keypartition based on the first letter (e.g., an ASCII char value or char)in a surname (e.g., a string/array of ASCII char values or chars). Sosurnames whose first letter is between A-H inclusive go to operatorinstance Inst 1, surnames whose first letter is between I-P inclusive goto operator instance Inst 2, and surnames whose first letter is betweenR-Z inclusive go to operator instance Inst 3. It will be appreciatedthat an accurate sum of unique values can be obtained in this use case.However, skewing might occur in this use case, as shown by the boldarrows going from the input to Inst 1 and from Inst 1 to the unifier, ifthe values being input show a skewed distribution (e.g., most of theinput surnames have first letters between A-H inclusive).

FIG. 28B is a diagram showing a use case that uses partitionableunifiers, in accordance with an example embodiment. It will beappreciated that this figure involves operations similar to thosedepicted in FIG. 27. To some extent, the functionality described in thisuse case combines the load-balancing of the functionality described inuse case 2 with the sticky-key functionality described in use case 3. Inuse case 4 depicted in this figure, the values are distributed betweenthe three operator instances (Inst 1, Inst 2, and Inst 3) using around-robin scheme that results in each operator instance receivingapproximately 33.3% of the values. Each of the operator instances keepsa count of unique values and emits those unique values to a group ofpartitionable unifiers (labeled “P_Unif 1”, “P_Unif 2”, and “P_Unif 3”)using a sticky-key partition based on the first letter (e.g., an ASCIIchar value or char) in a surname (e.g., a string/array of ASCII charvalues or chars). So as shown in the topmost box labeled 2801, operatorinstances Inst 1, Inst 2, and Inst 3 each emit unique values of surnamesbeginning with a letter between A-H inclusive to partitionable unifierP_Unif 1. As shown in the middle box labeled 2802, operator instancesInst 1, Inst 2, and Inst 3 each emit unique values of surnames beginningwith a letter between I-P inclusive to partitionable unifier P_Unif 2.And as shown in the bottommost box labeled 2803, operator instances Inst1, Inst 2, and Inst 3 each emit unique values of surnames beginning witha letter between R-Z inclusive to partitionable unifier P_Unif 3. Eachof the partitionable unifiers creates its own count of unique values andthen transmits the count to a unifier (labeled “Unif”) that sums thecounts. In an example embodiment, the sum might replace the countsinitially made by operator instance Inst 1, operator Inst 2, andoperator Inst 3.

In FIG. 28B, the example uses surnames (e.g., a string/array of ASCIIchar values or chars) as the values input to the partitioned operatorinstances. This example is not meant to be limiting. In the same or analternative embodiment, the values input to the partitioned operatorinstances might be integers, floating point numbers, enumerated values,or any other ordinal values, whether individually or in a collectionsuch as an array or list. It will be appreciated that partitionableunifiers, as described in FIGS. 27 and 28B, allow the computation ofunique (or distinct) values in a scalable and distributed fashion.

In an example embodiment, the operations described in FIGS. 27 and 28Bmight be implemented as platform functionality. In such an embodiment,the sticky-key partition amongst the partitionable unifiers might beperformed using a function call, e.g., Get_Partionable_Unifier_Key.

Though some of the embodiments described above have involved a stockticker, they are intended as illustrative rather than limiting. Inanother example embodiment, some or all of the operations describedabove might be used with online machine learning (including onlineactive learning) where predictions are compared with subsequent feedbackreceived from a data stream (e.g., a stock ticker) or a humanclassifier/labeler. Or some or all of the operations described abovemight be used to provide pricing in real time to a stock exchange, anadvertising exchange, or other online market. Also, some or all of theoperations described above might be used for analyzing websites,targeting ads, recommending goods or services, providing search resultsor other responses to queries, geo-positioning including geo-location,inventory analysis, online gaming including social gaming, networkrouting including routing in wireless networks, etc. Or some or all ofthe operations described above might be used for security includingfraud detection, outage detection (e.g., in a data center), or otheranalyses of event data (including sensor data), in real time.

In an example embodiment, advertising models that use bidding mechanismscan also benefit from near real-time performance analysis, which enablesbuyers and sellers to make faster changes to ad pricing or inventoryadjustments.

Returning to FIG. 1, personal computer 102 and the servers in website104 and website 105 might include (1) hardware consisting of one or moremicroprocessors (e.g., from the x86 family, the PowerPC family, the ARMfamily, etc.), volatile storage (e.g., RAM), and persistent storage(e.g., a hard disk or solid-state drive), and (2) an operating system(e.g., Linux, Windows Server, Mac OS Server, Windows, Mac OS, etc.) thatruns on the hardware. Similarly, in an example embodiment, mobile device103 might include (1) hardware consisting of one or more microprocessors(e.g., from the ARM family, the x86 family, etc.), volatile storage(e.g., RAM), and persistent storage (e.g., flash memory such as microSD)and (2) an operating system (e.g., Symbian OS, RIM BlackBerry OS, iPhoneOS, Palm webOS, Windows Mobile, Android, Linux, etc.) that runs on thehardware.

Also in an example embodiment, personal computer 102 and mobile device103 might each include a browser as an application program or as part ofan operating system. Examples of browsers that might execute on personalcomputer 102 include Internet Explorer, Mozilla Firefox, Safari, andGoogle Chrome. Examples of browsers that might execute on mobile device103 include Safari, Mozilla Firefox, Android Browser, and Palm webOSBrowser. It will be appreciated that users of personal computer 102 andmobile device 103 might use browsers to communicate (e.g., through agraphical user interface or GUI) with website software running on theservers at website 104. Alternatively, a users of personal computer 102and mobile device 103 might communicate with website 104 directly orindirectly (e.g., using a script) through a command line interface(CLI).

It will be appreciated that the above example embodiments includefunctionality that (1) enables a slave (e.g., STRAM Child) to monitoroperator instances in the slave's container and effectuate dynamicadjustments ordered by the STRAM; (2) generates streaming windows usingcontrol tuples inserted by an input adapter that creates data tuplesfrom an external data stream through the application of a schema; (3)displays data from data tuples in a GUI view using an output adapterthat removes control tuples; and (4) supports checkpointing on streamingwindow boundaries using checkpoint tuples inserted by an input adapter.

With the above embodiments in mind, it should be understood that theinventions might employ various computer-implemented operationsinvolving data stored in computer systems. Any of the operationsdescribed herein that form part of the inventions are useful machineoperations. The inventions also relate to a device or an apparatus forperforming these operations. The apparatus may be a general purposecomputer selectively activated or configured by a computer programstored in the computer. In particular, various general purpose machinesmay be used with computer programs written in accordance with theteachings herein, or it may be more convenient to construct a morespecialized apparatus to perform the required operations.

The inventions can also be embodied as computer readable code on acomputer readable medium. The computer readable medium is any datastorage device that can store data, which can thereafter be read by acomputer system. Examples of the computer readable medium include harddrives, network attached storage (NAS), read-only memory, random-accessmemory, CD-ROMs, CD-Rs, CD-RWs, DVDs, Flash, magnetic tapes, and otheroptical and non-optical data storage devices. The computer readablemedium can also be distributed over a network coupled computer systemsso that the computer readable code is stored and executed in adistributed fashion.

Although example embodiments of the inventions have been described insome detail for purposes of clarity of understanding, it will beapparent that certain changes and modifications can be practiced withinthe scope of the following claims. For example, some or all of theprocesses described above might be used with streaming media such asstreaming audio or streaming video. Or the hardware for the distributedstreaming platform might include a quantum computer (e.g., D-WaveSystem's quantum computer), along with or instead of traditional servers(e.g., in the x86 or ARM families). Moreover, the operations describedabove can be ordered, modularized, and/or distributed in any suitableway. Accordingly, the present embodiments are to be considered asillustrative and not restrictive, and the inventions are not to belimited to the details given herein, but may be modified within thescope and equivalents of the following claims. In the following claims,elements and/or steps do not imply any particular order of operation,unless explicitly stated in the claims or implicitly required by thedisclosure.

The example embodiments described in this disclosure include thefollowing: (1) a method, comprising the operations of: launching anapplication that runs on a streaming platform, wherein the applicationis structured as a directed acyclic graph (DAG) with instances ofoperators as nodes and streams as edges between nodes; receiving anindication that a first instance of an operator is I/O bound, wherein astream connects the first instance of an operator to a second instanceof another operator in a single container provided by the streamingplatform; transmitting the indication to the application and receiving arequest to combine the first instance with the second instance into asingle third instance of an operator; and creating the third instanceand re- initiating the stream using a recovery policy, wherein each ofthe operations is executed by one or more processors in real time ornear real time rather than offline; (2) a method as in (1), wherein theinstances of operators are program instructions and the streams areunbound sequences of streaming windows that are ordered in terms oftime; (3) a method as in (2), wherein each streaming window is an atomicmicrobatch of sequential structured tuples; (4) a method as in (1),wherein the indication includes a platform measurement as to resourceuse; (5) a method as in (4), wherein the platform measurement isthroughput of streaming windows; (6) a method as in (4), wherein theplatform measurement is throughput of tuples; (7) a method as in (1),wherein the third instance is created at least in part through compilerin-lining; (8) a method as in (1), wherein the request sets an attributeof the stream; (9) one or more computer-readable media persistentlystoring one or more programs, wherein the one or more programs, whenexecuted, instruct one or more processors to perform the followingoperations: launch an application that runs on a streaming platform,wherein the application is structured as a directed acyclic graph (DAG)with instances of operators as nodes and streams as edges between nodes;receive an indication that a first operator instance is I/O bound,wherein a stream connects the first operator instance to a secondoperator instance in a single container provided by the streamingplatform; transmit the indication to the application and receive arequest to combine the first operator with the second operator instanceinto a single third operator instance; and create the third operatorinstance and re-initiate the stream using a recovery policy, whereineach of the operations is executed in real time or near real time ratherthan offline; (10) computer-readable media as in (9), wherein theoperators are program instructions and the streams are unbound sequencesof streaming windows that are ordered in terms of time; (11)computer-readable media as in (10), wherein each streaming window is anatomic microbatch of sequential structured tuples; (12)computer-readable media as in (9), wherein the indication includes aplatform measurement as to resource use; (13) computer-readable media asin (12), wherein the platform measurement is throughput of streamingwindows; (14) computer-readable media as in (12), wherein the platformmeasurement is throughput of tuples; (15) computer-readable media as in(9), wherein the third instance is created at least in part throughcompiler in-lining; (16) computer-readable media as in (9), wherein therequest sets an attribute of the stream; (17) a method, comprising theoperations of: launching an application that runs on a streamingplatform, wherein the application is structured as a directed acyclicgraph (DAG) with instances of operators as nodes and streams as edgesbetween nodes; receiving an indication that a first operator instance isI/O bound, wherein a stream connects the first operator instance to asecond operator instance in a single container provided by the streamingplatform; transmitting the indication to the application and receiving arequest to combine the first operator with the second operator instanceinto a single third operator instance, wherein the request sets anattribute on a stream; and creating the third operator instance andre-initiate the stream, wherein each of the operations is executed byone or more processors in real time or near real time rather thanoffline; (18) a method as in (17), wherein the indication includes aplatform measurement as to resource use; (19) a method as in (18),wherein the platform measurement is throughput of tuples; (20) a methodas in (17), wherein the third instance is created at least in partthrough compiler in-lining.

The example embodiments described in this disclosure further include thefollowing: (1) a method, comprising the operations of: receiving anapplication that runs on a streaming platform, wherein the applicationis structured as a directed acyclic graph (DAG) with instances ofoperators as nodes and streams as edges between nodes and wherein theapplication is associated with a pre-defined hint that is a key-valuepair; launching the application by assigning the instances of operatorsto containers provided by streaming platform and initiating the streams;reading a value for the pre-defined hint and transmitting the value tothe application through an application programming interface (API)exposed by the streaming platform; receiving a request from theapplication through the API to make a dynamic adjustment; and making thedynamic adjustment and re-launching the application using a recoverypolicy, wherein each of the operations is executed by one or moreprocessors in real time or near real time rather than offline; (2) amethod as in (1), wherein the instances of operators are programinstructions and the streams are unbound sequences of streaming windowsthat are ordered in terms of time; (3) a method as in (2), wherein eachstreaming window is an atomic microbatch of sequential structuredtuples; (4) a method as in (1), wherein the dynamic adjustment includesa dynamic partition of an instance of an operator into a plurality ofinstances; (5) a method as in (4), wherein the instance of the operatorreads from and/or writes to a hash table or hash map associated with theinstance; (6) a method as in (5), wherein the pre-defined hint is acount of entries in the hash table or hash map; (7) a method as in (6),wherein the application makes the request upon determining that thecount exceeds a limit that is pre-defined; (8) a method as in (6),wherein the application makes the request upon determining that thecount exceeds a limit that is dynamically determined; (9) one or morecomputer-readable media persistently storing one or more programs,wherein the one or more programs, when executed, instruct one or moreprocessors to perform the following operations: receive an applicationthat runs on a streaming platform, wherein the application is structuredas a directed acyclic graph (DAG) with instances of operators as nodesand streams as edges between nodes and wherein the application isassociated with a pre-defined hint that is a key-value pair; launch theapplication by assigning the instances of operators to containersprovided by streaming platform and initiate the streams; read a valuefor the pre-defined hint and transmitting the value to the applicationthrough an application programming interface (API) exposed by thestreaming platform; receive a request from the application through theAPI to make a dynamic adjustment; and make the dynamic adjustment andre-launching the application using a recovery policy, wherein each ofthe operations is executed in real time or near real time rather thanoffline; (10) computer-readable media as in (9), wherein the instancesof operators are program instructions and the streams are unboundsequences of streaming windows that are ordered in terms of time; (11)computer-readable media as in (10), wherein each streaming window is anatomic microbatch of sequential structured tuples; (12)computer-readable media as in (9), wherein the dynamic adjustmentincludes a dynamic partition of an instance of an operator into aplurality of instances; (13) computer-readable media as in (12), whereinthe instance of the operator reads from and/or writes to a hash table orhash map associated with the instance; (14) computer-readable media asin (13), wherein the pre-defined hint is a count of entries in the hashtable or hash map; (15) computer-readable media as in (14), wherein theapplication makes the request upon determining that the count exceeds alimit that is pre-defined; (16) computer-readable media as in (14),wherein the application makes the request upon determining that thecount exceeds a limit that is dynamically determined; (17) a method,comprising the operations of: receiving an application that runs on astreaming platform, wherein the application is structured as a directedacyclic graph (DAG) with instances of operators as nodes and streams asedges between nodes and wherein the application is associated with apre-defined hint; launching the application by assigning the instancesof operators to containers provided by streaming platform and initiatingthe streams; reading a value for the pre-defined hint and transmittingthe value to the application through an application programminginterface (API) exposed by the streaming platform; receiving a requestfrom the application through the API to make a dynamic adjustment; andmaking the dynamic adjustment and re-launching the application, whereinthe dynamic adjustment includes a dynamic partition of an instance of anoperator into a plurality of instances and wherein each of theoperations is executed by one or more processors in real time or nearreal time rather than offline; (18) a method as in (17), wherein theinstance of the operator reads from and/or writes to a hash table orhash map associated with the instance; (19) a method as in 18, whereinthe pre-defined hint is a count of entries in the hash table or hashmap; and (20) a method as in 19, wherein the application makes therequest upon determining that the count exceeds a limit that ispre-defined.

And the example embodiments described in this disclosure include thefollowing: (1) a method, comprising the operations of: receiving anapplication that runs on a streaming platform, wherein the applicationis structured as a directed acyclic graph (DAG) with operators as nodesand streams as edges between nodes and wherein the application includesan operator that receives a plurality of values, counts the values thatare unique, and emits the unique values in a stream; partitioning theoperator into at least two partitioned instances; assigning a uniquevalue emitting from a partitioned instance to one of a plurality ofunifiers according to a pre-defined scheme, wherein each unifier createsa count of the unique values received by the unifier; transmitting thecounts from each of the unifiers to a downstream instance of an operatorthat aggregates the counts into a sum; and displaying the sum in agraphical user interface (GUI), wherein each of the operations isexecuted by one or more processors in real time or near real time ratherthan offline; (2) a method as in (1), wherein the instances of operatorsare program instructions and the streams are unbound sequences ofstreaming windows that are ordered in terms of time; (3) a method as in(2), wherein each streaming window is an atomic microbatch of sequentialstructured tuples; (4) a method as in (1), wherein the partitioning isstatic partitioning in a specification for the application; (5) a methodas in (1), wherein the partitioning is dynamic partitioning based onresults of monitoring the partitioned instances; (6) a method as in (1),wherein the pre-defined scheme is ASCII; (7) a method as in (1), whereinthe pre-defined scheme is numerical; (8) a method as in (1), wherein thepartitioning results in a round-robin distribution of values to thepartitioned instances; (9) a method as in (1), wherein the values arevalues in a key-value table or a key-value map; (10) one or morecomputer-readable media persistently storing one or more programs,wherein the one or more programs, when executed, instruct one or moreprocessors to perform the following operations: receive an applicationthat runs on a streaming platform, wherein the application is structuredas a directed acyclic graph (DAG) with operators as nodes and streams asedges between nodes and wherein the application includes an operatorthat receives a plurality of values, counts the values that are unique,and emits the unique values in a stream; partition the operator into atleast two partitioned instances; assign a unique value emitting from apartitioned instance to one of a plurality of unifiers according to apre-defined scheme, wherein each unifier creates a count of the uniquevalues received by the unifier; transmit the counts from each of theunifiers to a downstream instance of an operator that aggregates thecounts into a sum; and display the sum in a graphical user interface(GUI), wherein each of the operations is executed in real time or nearreal time rather than offline; (11) computer-readable media as in (10),wherein the instances of operators are program instructions and thestreams are unbound sequences of streaming windows that are ordered interms of time; (12) computer-readable media as in (11), wherein eachstreaming window is an atomic microbatch of sequential structuredtuples; (13) computer-readable media as in (10), wherein thepartitioning is static partitioning in a specification for theapplication; (14) computer-readable media as in (10), wherein thepartitioning is dynamic partitioning based on results of monitoring thepartitioned instances; (15) computer-readable media as in (10), whereinthe pre-defined scheme is ASCII; (16) computer-readable media as in(10), wherein the pre-defined scheme is numerical; (17)computer-readable media as in (10), wherein the partitioning results ina round-robin distribution of values to the partitioned instances; (18)computer-readable media as in (10), wherein the values are values in akey-value table or a key-value map; (19) a method, comprising theoperations of: receiving an application that runs on a streamingplatform, wherein the application is structured as a directed acyclicgraph (DAG) with operators as nodes and streams as edges between nodesand wherein the application includes an operator that receives aplurality of values, counts the values that are unique, and emits theunique values in a stream; partitioning the operator into at least twopartitioned instances, wherein the partitioning is static partitioningin a specification for the application and the partitioning results in around-robin distribution of values to the partitioned instances;assigning a unique value emitting from a partitioned instance to one ofa plurality of unifiers according to a pre-defined scheme, wherein eachunifier creates a count of the unique values received by the unifier;transmitting the counts from each of the unifiers to a downstreaminstance of an operator that aggregates the counts into a sum; anddisplaying the sum in a graphical user interface (GUI), wherein each ofthe operations is executed by one or more processors in real time ornear real time rather than offline; (20) a method as in (19), whereinthe pre-defined scheme is ASCII.

What is claimed is:
 1. A method, comprising the operations of: receivingan application that runs on a streaming platform, wherein theapplication is structured as a directed acyclic graph (DAG) withinstances of operators as nodes and streams as edges between nodes andwherein multiple instances of an operator access a shared database;setting a maximum period of time for a local caching of a result from aquery of the database by each of the multiple instances; launching theapplication by assigning the instances of operators to one or morecontainers provided by the streaming platform, wherein each container isa process associated with a local cache that is an allocation ofvolatile memory created by the streaming platform on an as needed basisand that performs the local caching; receiving a request from theapplication through an application programming interface (API) to make adynamic adjustment that increases the maximum period of time for thelocal caching of a result from a query of the database; and executingthe dynamic adjustment and re-launching the application using a recoverypolicy, wherein each of the operations is executed by one or moreprocessors in real-time or near real-time rather than offline.
 2. Themethod as in claim 1, wherein the instances of operators are programinstructions and the streams are unbound sequences of streaming windowsthat are ordered in terms of time.
 3. The method as in claim 2, whereineach streaming window is an atomic sequence of sequential structuredtuples.
 4. The method as in claim 1, further comprising, monitoring aperformance statistic for accesses to the database by each of themultiple instances and transmitting results of the monitoring to theapplication through the API exposed by the streaming platform.
 5. Themethod of claim 1, wherein the query of the database is processed byeach of the multiple instances.
 6. The method of claim 1, wherein saidlaunching further causes initiation of the streams.
 7. A method as inclaim 1, wherein the performance statistic measures one of throughput,or keys read, or keys written.
 8. Computer readable media havingnon-transitory programming instructions for processing an application,comprising: program instructions for receiving the application that runson a streaming platform, wherein the application is structured as adirected acyclic graph (DAG) with instances of operators as nodes andstreams as edges between nodes and wherein multiple instances of anoperator access a shared database; program instructions for setting amaximum period of time for a local caching of a result from a query ofthe database by each of the multiple instances; program instructions forlaunching the application by assigning the instances of operators to oneor more containers provided by the streaming platform, wherein eachcontainer is a process associated with a local cache that is anallocation of volatile memory created by the streaming platform on an asneeded basis and that performs the local caching; program instructionsfor receiving a request from the application through an applicationprogramming interface (API) to make a dynamic adjustment that increasesthe maximum period of time for the local caching of a result from aquery of the database; and program instructions for executing thedynamic adjustment and re-launching the application using a recoverypolicy, wherein each of the operations is executed by one or moreprocessors in real-time or near real-time rather than offline.
 9. Thecomputer readable media of claim 8, wherein the instances of operatorsare program instructions and the streams are unbound sequences ofstreaming windows that are ordered in terms of time.
 10. The computerreadable media of claim 9, wherein each streaming window is an atomicsequence of sequential structured tuples.
 11. The computer readablemedia of claim 8, further comprising, program instructions formonitoring a performance statistic for accesses to the database by eachof the multiple instances and transmitting results of the monitoring tothe application through the API exposed by the streaming platform. 12.The computer readable media of claim 8, wherein the query of thedatabase is processed by each of the multiple instances.
 13. Thecomputer readable media of claim 8, wherein said launching furthercauses initiation of the streams.
 14. The computer readable media ofclaim 8, wherein the performance statistic measures one of throughput,or keys read, or keys written.